Policy Implementation Report
 










00:02 Madhvi Gokool: Thank you, Seun. Good afternoon, ladies and gentlemen. I'm Madhvi Gokool, Registration Services Manager at AFRINIC, and I'm representing to you the policy implementation experience report. So, the first policy that we look at is the IPv4 location policy and in there it's mentioned that AFRINIC is responsible for the location of IP address space, AS numbers, and management of reverse domain names within the region.

00:42 Madhvi Gokool: So the current practices that we look at the legal presence of the entities in the AFRINIC service regions. We also look at the proof of infrastructure and operation in AFRINIC service regions, proof of that the providing services to end users, evidence of connectivity and operation. In some cases where applicable, we also ask request for the license that they have from the regulator to operate. That would mostly apply to internet service providers and we would slow start us for the policy by default unless justification for more IP addresses is made and given to us that would prove that the entities have existing network operations.

01:39 Madhvi Gokool: The issues that we faced, that we have request from companies with offshore presence in our service region. By offshore presence, that means that they have an offshore registration in the region but they are not allowed to do business in the country in which they got the offshore certificate of global business license. So, we have also request in which it's mentioned that they have partnerships regarding infrastructure with no further details being given to us, that the leasing equipment and co-location in data centers, so before they were purchasing infrastructure equipment, now it's leasing of equipments. Some of the request we're getting is, before even like the organizations are established in our region, we would ask for legal presence evident in the region and then we'll see the certificate of incorporation or a document coming to us and it was done after our request was made. And we also have an issue regarding VSAT operators who have co-infrastructure located outside the AFRINIC service region.

03:25 Madhvi Gokool: So in terms of statistics, for the past six months we have received nine resource member request from offshore companies. None of them have been brought to closure yet because they were not satisfying the requirements that we have in place. And we also have a request from one VSAT provider who says they're servicing customers in our service region. Now, for the VSAT operators, usually what we recommend to them at the moment, for the past two or three years I think we've been doing that, we do not want to penalize the African entities that are buying bandwidth from them, so some African entities have come to AFRINIC to get their IP resources and then they ask the VSAT operator to route it for them. So the VSAT operators are actually the upstream providers for those organizations. We also have other ISPs, LILs in our region who are providers, I mean for which VSAT operators target customers in our service region and through those ISPs the African entities have been able to access the internet through the VSAT service. So, that was work around.

05:05 Madhvi Gokool: The same policy also states that an LIL can receive an additional location when about 80% of all the address space currently allocated to it has been used in valid assignments and/or several locations. So, this came up with a clarification in the morning. We do look at percentage usage of the aggregated space but the way we evaluate request is we audit each allocation that has been issued to the organization when they come for an additional space. So we audit what hasn't been audited until the organization, our member, has reached a size where we look at the overall picture.

06:00 Madhvi Gokool: So, basically we'll audit the full... All the utilization and is it 80% of all the requested... Of all the resources they have in hand. We also verify the validity of the assignments in terms of historical data that they keep and sometimes the snapshots of usage data and bandwidth, so there's a mix of documentation that they supply just show the validity of the assignments. This is important because sometimes or most of the time, what's registered on the Whois database does not in fact reflect the utilization. While we were doing the audits that's what we found out, I mean a /14 split into and registered as two separate assignments on the Whois database that shows 100% utilization on the member portal, but in fact due to wrong provisioning they were not being used up to 80% even though the Whois database shows 100% utilization.

07:12 Madhvi Gokool: So as part of a check, we also verify if the prefixes we've issued appear in the internet routing table because the public IP address space especially when the services that were mentioned for the deployment of this IP addresses, so mentioned access to the internet, so it has to be routed. And usually if we do not see it routed we do ask a couple of questions about it. And where our members have not registered the utilization of their prefixes on the Whois database, we use some teach and approve mechanisms so that you have this one-to-one interaction with the registration service team so that they can properly manage the IP addresses. We talk about how they should look at the address planing needs carefully, provision the network, and once after they provision the network, they should be registering the assignments on the Whois database. So we do have them with it, even though they have after the first interaction they may have further queries, they may need us to show it to them again, we're willing to help them with it.

08:41 Madhvi Gokool: So statistics wise, I have requested our team in Mauritius to look this up and we found that 538 AFRINIC LIR members that had received an IP prefix from AFRINIC between the 1st of January 2005 until 31st of May... Sorry, 2014. I'm sorry, there's a typo there, 2014, do not have 80% utilization on the MyAFRINIC portal. Why is 2014 is because we give resources up to a year, okay. So I haven't taken the past 12 months into consideration. Knowing that we have about 1200 members, 1100 members is roughly 50% of our members that right now if we look at Whois database in terms of registration of the usage of the IP addresses, they're not policy compliant.

09:47 Madhvi Gokool: We have another policy, the end user assignment policy. It states that organization should show either existing efficient utilization of at least, at less /25 from the upstream provider or they should justify an immediate need of at least 50% of what they're requesting based on the network infrastructure. So we look for policy compliance in this case, IP addressing plan helps... Where they have to justify their needs and in some cases where we, as host masters, we feel that they're not looking at the bigger picture of the organization. Some of them still focus on what they have from the upstream, a /27 or a /28 and they only ask for that and forgetting that they're NAT-ing most of the internet users, so they're still using that on the network. And so we teach and approve them so that they can provide an adequate IP addressing plan so that they are also made aware that they can do away with NAT on the network when after they received their IP blocks.

11:08 Madhvi Gokool: Some issues that we faced, yes, they cannot justify the need for the minimum for their operations. Some of them, they may not be able to justify an immediate need to comply with this policy, but they are able to comply with the ASN policy for the AS numbers. They have two BGP Peers but they can't get at least the minimum /24 to use on the network because that ASN policy, it's only for AS numbers and the end user assignment policy does not have as criteria that any organization that is eligible to get an ASN can also get the minimum so it's not in the policy there. And one of the latest cases that we observed were, that some end users were not looking at their needs in overall, despite teaching them about it. And they were coming back before a year, before six months, I think in fact, to get IPs for their disaster recovery site. So we trying to update our documentation on this side, as well just so that to make them aware that they should be looking at all their needs for the next 12 months because that's the amount of time that AFRINIC will allocate resources for, as per an existing policy.

12:41 Madhvi Gokool: In terms of mergers and acquisitions, we do not have a policy at AFRINIC, we only have a guideline that we use because we are aware that it could be a merger, sale or takeover, so in the guideline it's publicly available on our website. So we ask... Operationally we will ask for detailed information about the transfer case. We will have to check if there have been changes in ownership due to merger, sale or takeover, or if the members stop serving entirely as an LIR.

13:24 Madhvi Gokool: We have had a consolidation request for resources being consolidated under holding companies. But in terms of transfers due to mergers and acquisitions, we only do so if there is evidence of merger, sale or takeover. The issues that we have observed were transfer requests are being received, and the non-merger, non-acquisitions related. Transfer from one organization to a sister organization for example, from one LIR to another. Now what we've seen is legacy resource holders want to transfer their IP address base, or some of it, to another entity that they say is related to them or that they say were bought by them, all the strict operations now there's another entity that is that want some of this space.

14:34 Madhvi Gokool: We also have change of name request without relevant documentation as proof. Change of name request usually have to be accompanied by a certificate of change of name. And for change of name request, is our members, and if I may say so based on a discussion that happened a year on, is also regarding legacy resource holders. The legacy resource holders at some point in time want to update their organization details, their contact information, their address. So they want to do it. They want to update their maintainer. So they come into us because their resources are registered in a AFRINIC Whois database.

15:20 Madhvi Gokool: These mergers and acquisitions are very time and resource intensive. We as staff have to make all the checks that are needed and be very diligent that resources are not being [15:34] ____ by an entity that's saying that, "Yes, we bought them." We do ask the buyer and the seller, both parties, to agree to it. We have had cases where the seller then comes and says, "No, no, no, the IPs should not be transferred over to that the organization that acquired my customers and my infrastructure, okay. So it's becoming more complex. So statistics wise, right now we have 10 requests for resource transfers that are not yet concluded. They pressing us for speedy conclusion, but unfortunately we haven't been able to conclude any of them yet.

16:34 Madhvi Gokool: The ASN policy states that there are three requirements, pre-requisites, that an organization could satisfy to get an autonomous system number. So the current practice that we observe is that we verify if they at least specify to BGP Peers, and we contact those BGP Peers to get them to confirm the peering agreement with them. We also ask them if they are connecting to an internet exchange point, because at AFRINIC we consider an organization to be multi-homing as well if you're connecting to an internet exchange point because internet exchange points, by default have at least three BGP Peers connecting to them. We also check if they have a unique routine policies. That happens in the case of some organizations. And we will approve in the majority of the cases if both peers have confirmed immediately, or our member wants to multi-home, and they tell us that it will occur, the multi-homing, would occur in a reasonable amount of time, and that reasonable amount of time, we have assumed to be three months.

18:04 Madhvi Gokool: So there are issues that we have faced so far... ASN requests coming to us with only one BGP Peer mentioned, peers would not confirm peering agreement when we contact them. Some members assume, or presume that they can only use their IP resources if they have the public AS number. And we have also been told that some upstream ISPs are making it a mandatory requirement for their customers to come to them with a public AS number. But if that customer is single-home they would not comply with the AFRINIC policies. We have the latest... This is the Reverse Delegation. So, No Reverse Unless Assigned Policy. So AFRINIC will no longer grant reverse delegation of IP address space, that it administers unless an assignment of sub-allocation of the specific address space is registered appropriately in the AFRINIC database. So the current practice is that we have updated our business rules as part of the policy implementation.

19:20 Madhvi Gokool: We have also hard-coded it into the member portal and on the Whois database, so that reverse DNS are not registered unless there is at least one assignment registered for the prefix. We have also been teaching the members who face the difficulties because now they're caught unawares. Reverse DNS is important for them. They want to register on the Whois database and they get another error adding assignments and they have no clue about it, about what to do with it. So we had to really work with them, hard with them to at least get them to understand. And it's a other opportunity for us to ensure that our members register the assignments on the Whois database. I requested some statistics. We had... Some had 200 members that were not policy compliant last year in September. Right Annis? If I'm not mistake. September last year when we implemented the policy and as of now we have 181 LIR members that are not policy compliant.

20:38 Madhvi Gokool: They updated the data. And in the past six months, my host-masters are telling me that we have attended to about 140 tickets regarding the No Reverse Unless Assigned Policy because of our members who could not, you know... They couldn't understand why they could not register their Reverse DNS. Some of them received our communication and wanted to know if they were compliant or not, so we had to go double-check everything, work with them so that they're compliant. The issues that were the slow uptake... We had to do some training for our members and we had to deal with a larger volume of tickets. In the IPv6 Policy, that's for allocation and assignments of IPv6 space, 6.4.1 is regarding the assignment adjust space size. So we had followed these guidelines when implementing this policy way back a long time ago, I would say. And what we have seen is the evolution that our members now want to register different assignment size and at the moment, they are only limited to such assignment size.

22:13 Madhvi Gokool: So we have discussed it internally, and the policy also states that AFRINIC is not concerned about which address size an LIR actually assigns. So we're basing ourself on this and we will further allow our... The LIR members is still pending coding at the moment to register any assignments that they feel works for their networks. The end result will be that we would have an updated database, Whois database, regarding registration and usage of the IP addresses. So moving forward, the IPv4 Location Policy also has one section regarding sub-allocations where the sub-allocation size is a /24 and the scope behind the sub-allocation is, it allows a reasonable number of small assignments to be made by a downstream ISP. So sub-allocations are usually done to an ISP who's a customer of a bigger LIR. We have seen an evolution where we have a reseller virtual ISPs model that is being adopted in some of the regions that we provide IP addresses to. And the LIRs were facing difficulties in that, in fact, just define the usage of their prefix that they receive from AFRINIC and were telling us, "No, no, no. We don't have any visibility on how the IPs are being used.

24:02 Madhvi Gokool: So what We have done is, we've worked with those LIRs, so that they request for sub-allocations, and then we're teaching and approving them. We're teaching them in how they should manage, because sub-allocation is not the end. Those IPs will still be issued to the customers, the end users there. And we want to see the usage data registered accurately on the Whois database. So, what we've done is, those LIRs will also have reseller models, we request them to request for sub-allocations and also, they are told that the actual usage would be once the assignments are registered on the Whois database. With the advent of more policies being ratified in the past three years, especially the past year, I would say that we have started receiving resource request, in which the IP addressing needs would actually have may have made us look into different policies in order to be able to evaluate them. One such example was the IPv4 location... Request, couple of requests I think, that had Anycast assignment needs in there as well as IP addresses for regular service. For the regular service, so that meant that, we had... We thought about it properly and came to the conclusion that we would evaluate, we would look at IP addressing plan, and evaluate the request based on the policy that is applicable to them.

26:08 Madhvi Gokool: If there's more than one policy, we would... You would take out each section and evaluate it as per the policy that is applicable to them, so that we do not penalize the member requesting for the IP resources. And we also be able to tell them clearly what is happening where, and if you have had to limit them on certain cases, the reason behind it. Example, the Anycast assignment they allowed only one assign Anycast. So, I will request to the communities, shall AFRINIC registration services carry on with its current practices? Knowing that current practice would reflect on AFRINIC as an organization. You may come forward, if you have any questions, suggestions, or you can also use the policy discussion, [27:09] ____ less if you have any questions in this regard. Thank you very much.

27:17 Barry Macharia: Andrew, you have a comment? 

27:18 Andrew Alston: Yeah, I've got two questions and one comment.

27:23 Barry Macharia: Andrew, introduce yourself.

27:26 Andrew Alston: Andrew from Liquid Telecom.

27:28 Madhvi Gokool: Thank you.

27:29 Andrew Alston: Firstly with a question, when you mention that you verify, whether or not space is announced in the routing tables, just as a matter of curiosity, do you look at the AS clause where that space is announced from, and who is actually announcing it when you look at it? So, that's question number one. Question number two: You referred to many many users, who don't have accurate data in the Whois database or haven't assigned, use their space et cetera, do you feel that this is because people simply aren't updating the information, or because they actually aren't using the space? Do you have any sense of that? And do you believe the implementation of stuff like REST APIs will assist the situation, and if so, when will REST APIs become available to the public? And then lastly, as a comment, with regards to the acquisitions, mergers, and transfers, and consolidations, I would personally like, on behalf of liquid telecommunications, to say a huge thank you to the AFRINIC host masters and staff for an excellent job well done. We have...

[applause]

28:52 Andrew Alston: I can tell you before this audience that of anybody doing consolidations, and I'm sure Madhvi will attest to this. I don't think she's ever seen so many consolidation requests in her life that's came from me. They were long, they were comprehensive, but they were dealt with, and we've just done another one, and happily once I provided the documentation as requested, I believe it took less then 72 hours to do and AFRINIC staff have done an excellent job there and they really need to be commended for it. So, thank you very much on behalf of Liquid.

[applause]

29:31 Barry Macharia: Madhvi, do you want to go to that comment or we go to next...

29:34 Madhvi Gokool: I will have to reply to some of that.

29:36 Barry Macharia: Okay.

29:37 Madhvi Gokool: Okay. When we check the routing table, yes, we have an idea of what an AS path is. The Registration Service Agreement has some clause, when you request for IP address space, if it's changed, what you requested for if it has changed, then you have to inform AFRINIC about it, it has a clause about it.

30:02 Madhvi Gokool: We do not go enforcing it as a rule but in case when we receive additional resource request, or if somebody is telling us we have that much amount of space and we're using it, we'll find out. I mean if you are using it then it should be visible on the internet. Unless you have a reason, and you tell us about it, we wouldn't know about it, so we will ask you why if it's not. So sometimes we have seen couple of cases where they will mention their upstream provider, it will be this organization and then eventually when it goes, when it's been routed, it gets routed on the AS number,  ____ the upstream providers. So because we do refer to the history of their locations that we've done, such things come to our attention and if we think we have to ask the member about it, we'll just ask the question. It's not that... They would have a reason, that's definitely so and we have... They have happily... Some of them have happily provided us an explanation.

31:13 Madhvi Gokool: They have decided to change upstream providers in mid course, for some reasons so yes, we sometimes look at the AS. And especially like sometimes if we are not so sure of the request, something is bothering us and these are the advanced checks that we would actually use but not as a rule. But we do check if it's been routed, we had couple of issues with Liquid as well. But we do check for the routing. That's just part of the job. Now regarding the utilization, registration of the utilization, it so happens and speaking based on experience that when our members come for additional resource request, they may not have registered it on the Whois database, maybe because they don't know how to do it or they don't find the time how to do it. I haven't done the survey in that regard yet but I have to keep that in mind. But it could... But when we ask them that you haven't registered it but we need to know how you've using the address space, and they come up with nicely documentation that is kept, okay.

32:33 Madhvi Gokool: They've kept a documentation or sometimes they will submit the documentation as to how we're using the address space with the request, but they haven't done the last mile, the extra mile and registered them on the Whois database. So as a rule, what we do is we will tell them we evaluate it, "we're evaluating your request but before we can issue, you have to register on the Whois database." So then we work with them and that is... That takes time, it's a one to one using a remote session WebEx or TeamViewer only thing applicable that can work so we help them in doing like the first three or four then we tell them you are on your own, now you can go and update and they do update, okay. We do not issue more resources unless the Whois database has been properly updated. Regarding the rest APIs, we do have the member portal, MyAFRINIC portal. It works for the small members, yes it works for the small members because it has a GUI. So they just fill it and... But it's... When they have a lot of assignments so as they are growing, then it doesn't scare that much.

33:57 Madhvi Gokool: Remember registration of the usage happens on the Whois database, so the MyAFRINIC portal is just a tool that they would use to write to the Whois database. So for some of them, especially the big ones, we work with the technical context, so they can do a bulk update using Whois client or by email or using the Whois client on our website, that has been upgraded couple of years back if I'm not mistaken, to cater for that. So it's more intuitive as well there. Now the work on the MyAFRINIC, the member portal we feel based on our experience, based on the type of request that we receive, we feel that it has to be enhanced. Now, how it will be enhanced, what are the features? Now I would request you, okay. Use the member's, discuss mailing list, okay, and start putting down, we had couple of requests, we know Andrew that you want the rest interface so we know that.

35:07 Madhvi Gokool: Now if our members, so we've heard I think, personally I think we have heard from about... I have received communication from about five or six members and I've already documented those requests as our members feel that these are good to have, but we want to hear from more members as well. If it is something that they think it will help them, then AFRINIC management would have a look and decide on the way forward.

35:42 Andrew Alston: If I just might make a comment just for the information of the audience as to why I mentioned the rest APIs. If you look a lot of the IPAM systems up there, the IP management systems, particularly the higher end one's used by large operators. We personally use 6connect, which I still think is the best IPAM system on the planet. But 6connect, Infoblox, and various of the other more commercial grade systems, all of those systems do talk REST.

36:20 Andrew Alston: Now, that has a huge advantage because when, for example, my engineers login there and they allocate IPs to a particular purpose, when they click a single button that says allocate, it would automatically populate the Whois data, which means that I don't have to go back and run a whole separate process to either modify it via the GUI or do email bulk updates or anything else. It is actually built into the IPAM systems out there. And the REST API integration was put in to those IPAM systems from my understanding and from conversations with guys like Aaron Hughes. Specifically, because the other RIRs already supported it really does have a lot of use.

37:07 Andrew Alston: So while I fully agree that we need more comments from other members et cetera I would like to hear other members comment on this and whether or not they're using IPAM systems that actually support REST.And yeah, I would really really appeal to the membership base to say speak up because if that's what AFRINIC is waiting for, then let's give them what they're waiting for and actually give it a voice on the members' list.

37:39 Madhvi Gokool: Thank you.

37:40 Barry Macharia: Madhvi, before you, react to the comment. Douglas, you're on the mic.

37:52 Douglas Onyango: Madhvi, you made a presentation in one of your slides, you are speaking about the transfer policies. You...

38:01 Madhvi Gokool: There's no transfer policy, it's just a guideline.

38:03 Douglas Onyango: Oh, yes. About the absence of a transfer policy and you made a note that you have about ten requests that are currently in pending state. I wanted to ascertain from you to what extent that is on account of the absence of a policy, so that I just wanted to figure out if immediate action is required on this, or if it's something that the request can actually be fulfilled whether or not a policy is enacted today. Thanks.

38:44 Madhvi Gokool: Okay. We base ourselves on the guidelines. In the past we have accepted mergers, and acquisitions happen so if there has been evidence in your off service continuity, so we have transferred the prefixes to the organization that is currently using them. But for cases where we cannot see any justification related to the guidelines that are on our website then we would have to decline the transfer request and eventually we would have to tell them, "The reason the guideline you did not comply but if you would like to present a policy in that regard then you may do so." So we have seen the evolution. In couple of cases we thought that we would decline but eventually it didn't come to that. The right people, that when they were involved then they gave us the documentation, the justification that was required, they could justify that there was service continuity so they got transferred. But a couple of cases that I have seen at the moment, we may have to decline them. So it's up to the AFRINIC community to decide what is the way they would prefer. If there's no evolution then we would carry on applying the guidelines that we have adopted.