[pause] 00:26 Ernest Byaruhanga : Good morning everyone. Thank you Seun for the intro. Mine is gonna be a quick one. We... I'm going to take you through two things. One, policies that have been implemented recently that might be of interest to the community. And right after that, we'll look at what could be of interest to us that the other regions are discussing. So we have gone ahead and picked, looked at what the other regions are talking about, what we think might interest us. We did not pick out everything, we're only picked out what we think might be of interest in the context of our region. So, when we get to that, I will talk about what is being discussed everywhere else apart from RIPE. RIPE, Marco would be able to come to the microphone and give us more insight on that when we get to that. 01:41 Ernest Byaruhanga : So, there are two policies that have been implemented recently that we thought we'd share with members and the community. The first one, Anycast assignments in the AFRINIC service region. This one actually was discussed more than one year ago, the first version of it. That first version was brought about because at the time of anybody that wanted space for use for Anycast in their services, there was no policy at AFRINIC that actually was providing guidance to AFRINIC staff to be able to issue Anycast space. So this policy was proposed and it was implemented initially, but the first version of it was only covering IPv4 space. The other types of resources, IPv6, and these numbers were not part of it. So, one of the community members came up and offered a revision of the same proposal to take care of IPv6 Anycast resources for those that need them as well as AS Numbers for those that need them for Anycast. 03:05 Ernest Byaruhanga : So, the way the proposal was written is such that if you need Anycast space, you can only get one /24 and that's it. So if you need more, the policy does not cater for you, and you might want to perhaps think of reviewing it if you think it does not meet your needs. That applies also to IPv6 space, if you need Anycast space for IPv6... IPv6 space for Anycast in your services, you still can only get one one /48. You can also as well get just one AS Number. I believe these are all in line with the recommendations in BCP 126 which is also I think an RFC who's number I just can't recall off head. I think it's 4876 or something like that. And I think that same RFC has roughly the same recommendations especially regarding IPv4 and the conservation of the IPv4 resource. 04:12 Ernest Byaruhanga : So that was... That's the first proposal that we thought we would share with you. So any members of the community that now want to acquire IPv4 space or v6 space, or AS number for Anycast in their services, there is now a policy that takes care of that, and if you have submitted a request before and it was not considered, please you can consider resubmitting it again and you'd be able to get just one /24. Please don't come for a /16 for Anycast, you won't get it. The policy doesn't take care of that. 04:49 Ernest Byaruhanga : The second one, no rDNS unless assigned. This one was actually implemented before the last meeting. It's just that we thought we'd also share it you because many members are still affected by this and there are still many support tickets that do come to AFRINIC regarding this issue. People of course, that are noticing that their reverse DNS service does not seem to be working and they are wondering why or maybe they missed the communication why. And the reason for that is because ever since this proposal, this policy was implemented, the no rDNS unless assigned policy, it touches local internet registries. And those that have taken IPv4 allocations and have not gone to the Whois database to register any IP space that they have issued to their customers, to their clients or to their down-stream networks or to their own network infrastructure, do not have access to reverse DNS services. 06:08 Ernest Byaruhanga : So, if you do notice that perhaps your reverse DNS service is not working or you cannot actually activate it in MyAFRINIC or in the Whois database, you might want to check whether you're affected by this policy proposal. Go into the Whois database or go into MyAFRINIC and see whether you have actually gone ahead to create or register any IP addresses that you have issued to your customers, to your clients, to your down-streams networks, to your own infrastructure in the Whois database, because if you haven't, then you will be denied reverse DNS services, and chances are that, this is because of this proposal... Implementation of this proposal in particular. So... Andrew, do you mind if the questions can come right after? Sorry, Chair, I think you should be the one to determine that. Okay, thank you. [background conversation] 07:10 Ernest Byaruhanga : So, these are the two main policies of interest that we thought we should share with you at this particular moment. There are others that have been implemented before, but these ones are still... There are still issues associated with these proposals that we thought we should share with the community, especially regarding the reverse DNS services and the Anycast resources. Next, I would briefly share with you what is being discussed in the other regions. Just a minute, Seun, would you like the questions to be taken just on this particular right now or what? 07:57 S?: This topic____. 07:58 Ernest Byaruhanga : Okay. Andrew, please carry on. 08:12 Andrew Alston: I just... First of all it's Andrew Alston here from Liquid Telecom. I just want a clarification as to whether or not that rDNS policy is also being applied with regards to the legacy space, because AFRINIC does handle the rDNS or legacy space, but beyond that, and that is purely as a result of legacy. However, AFRINIC has no right to put such determinations on legacy space since they're not bound by the RSA. So, can we please get clarification there? 08:49 Ernest Byaruhanga : Okay, I will try to answer that question from the knowledge I have, but Madhvi, if you feel you need to clarify, please, go ahead and do that, or if you want to answer it directly, please carry on. Okay. Sure. 09:12 Madhvi Gokool: Okay. From what was implemented, the policy applies to a LIR members, because there is no reverse DNS assigned. Most of our legacy resource holders in our region do not have allocated PI space, so I'm not sure if it's being applicable. There could be one, but, I don't. The cases that we have come across the assigned PIs, so, it may not affect them, but if there is a case that we catch and the community feels that it should not be applied to legacy resource holders, then we don't have to intervene on our side. 10:04 Ernest Byaruhanga : Okay. 10:04 Seun Ojedeji: Just a minute before Andrew... So, that is Madhvi from AFRINIC. So, please, try to mention your name and your affiliation before you make your comments. Go ahead Andrew. 10:18 Andrew Alston: It's Andrew here from Liquid again. I would like to ask, with the indulgence of the chair that this be verified and brought back to this community before the end of this meeting as it is an incredibly important point, considering that the vast amount of academic space that sits particularly in the SADC region relies on its reverse DNS. We have already have a massive reverse DNS failure once this year due to a flaw, and I don't want to see them being disenfranchised, so I would like an answer to this before the end of the meeting. 10:58 Ernest Byaruhanga : Okay, Andrew... [pause] 11:21 Ernest Byaruhanga : Andrew., we shall take a look at that and we do take your... Understand your concerns regarding legacy space holders. As Madhvi said, many of them tend to be assigned PIs not LIR allocations and the policy does not touch any other space other than LIR allocations, but we'll look into it and perhaps get back to you at the end of the day with any statistics that could help clarify that. 11:54 Seun Ojedeji: Yeah, Owen. Okay. 11:56 Madhvi Gokool: Madhvi, Registration Services Manager, AFRINIC. Just to add my clarification, as from the date of implementation of this policy, we have not had any end-user, member, or legacy resource holder who had an issue registering the reverse DNS on the Whois database. We have had no request of any difficulties, otherwise we would have already taken that into account. Thank you. 12:30 Owen DeLong: Owen DeLong here on Advisory Council. I think Andrew's point may be moot, and even if it's not moot, it maybe errant, anyway. I don't know what conclusion if any this region has come to regarding IR authority over legacy resources, but in the ARIN region, the determination has been that as the successor of registry to the previous registries, the policies do actually apply to legacy resources whether or not they have signed an RSA. 13:07 Ernest Byaruhanga : Thank you, Owen for that. Has that always been the case, or was that determined recently? Because I have followed a few discussions on the PPML list and they tend to imply that legacy resource holders are not touched by the RSA apart from the special Legacy RSA that they have signed. 13:27 Owen DeLong: There are many people... Well, they are not touched by the RSA, but they are touched by the ARIN policy document, the public policy... Number Resource Policy Manual. They are subject to the Number Resource Policy Manual and any operations on them in the registry must be in compliance with those policies. There are lots of people who make claims otherwise on the mailing list and elsewhere, but the consistent position of ARIN staff, the ARIN board, and ARIN's corporate council has been that as the successor registry, they do have the authority to implement the policies. And the policies do cover legacy resources as well. And those have so far been upheld in the court cases. 14:20 Andrew Alston: Andrew again here, from Liquid. I'd like to comment on this further because this issue has come up a number of times within this community over the past five or six years. And there has been no policy within this PDP to make legacy space subject to AFRINIC rules. And in fact it has been argued many times before this community and there is precedent that legacy space is not subject to this. I point to allocations that have been made to legacy holders where it has been determined that legacy space cannot be counted towards an evaluation of used space by the entity. University of the Free State point in case, University of the Northwest, point in case, University of Cape Town, point in case. So there is precedent to say that legacy space is outside of the auspices of AFRINIC control. 15:22 Ernest Byaruhanga : Okay. I think that we might have to escalate this issue to our legal folks and perhaps see if we can get a report for this and get their opinion on it, because regarding the process, Andrew is right. Andrew is right regarding the fact that legacy spaces are not considered when evaluating utilization of a v4 space for subsequent allocations. But I think that's beside the point of whether actual policies and any future policies will actually touch or affect legacy resource holders, and other legacy resources in the Whois database. I believe this is something that needs maybe further studied and perhaps maybe at a point in time we can involve our legal advisers and see if we can take it a step ahead. I believe this is not the time to give a conclusive answer on that, especially given that the other regions have looked at it and have a different view on it. Maybe it's something that they need to take a look at again. 16:35 Seun Ojedeji: Thank you, Ernest. Thank you to everyone as well. I think we move to the next item if there are no more comments. Any comments, any further comments on what has just been discussed? Okay. Let's move on please. 16:52 Ernest Byaruhanga: Thank you, Seun. [pause] 17:10 Ernest Byaruhanga : Okay. We went ahead and looked at the, what other regions are talking about and I'll quickly summarized a few of the policies that we thought we would share with the community here, in case if the community thinks that some of these maybe might touch our region and perhaps might be of interest to us. A quick look at what we picked from the ARIN region. The ARIN region, they have a discussion about how ARIN handles reorganizations. Reorganizations, I believe from the context of internal resource transfers regarding mergers and acquisitions, and if one company acquires the other, or if a department of one company acquires another, wants to transfer resources to another. This is something that is being discussed and I believe that such an issue has come up before on our mailing list regarding how AFRINIC handles internal transfers of IP blocks from one member organization to another organization, whether they're a member or not. 18:25 Ernest Byaruhanga : It is interesting that it has come up before and this is something we thought we would share. Then the second one that we thought was interesting, is the need to change utilization requirements for subsequent allocations, from considering the last used allocation to the total aggregate of the allocations that a member holds. I believe this is what it is. So, the way ARIN handles utilization or assessment of utilisation when giving out additional space to members is they were, I believe, looking to evaluating the utilization of the most recent allocation. And this proposal seeks to adjust that, so that they look at utilization of all allocations held by the member. I see Owen is trying to clarify that, and Owen, please feel free. 19:27 Owen Delong: Yeah. You are right about the intent of the proposal, I just wanted to clarify, it's no longer a proposal, it's a policy. It was adopted. 19:38 Ernest Byaruhanga : Oh, it was actually adopted, thank you for that Owen. So that actually was adopted. When was it? Was it recently or... Okay. So that was actually adopted recently by the ARIN community. So in our region, Madhvi again will have to correct me on this, when looking at utilization of the most recent space, I believe we look at the aggregate, Madhvi, or? Do we look at the aggregate or do we look at the last used allocation? Because this is, perhaps might have some bearing on some of our processes. 20:19 Madhvi Gokool: Okay. The interpretation of the policy at the moment is the org should have reached 80% utilization of aggregated space. But our members they range from the very small ones upto the large recourse requests. So during the evaluation of additional recourse requests, what we do is we audit the latest allocation. But as the number of prefixes grow for the organisation and IPs are spread all over their services, then we go for auditing aggregated space. But if we audited the previous time, it was 80%. We assume it has been audited. So the 80% rule still applies. Am I clear? 21:15 Ernest Byaruhanga : Yeah, you're clear. So it's the most recent allocation, last used allocation. Not aggregate. Unless... 21:20 Madhvi Gokool: It's 80% aggregated space, but when we do it in practice we'd still refer. If we they had 80% aggregated space in the last allocation, we audit that. And the previous ones were already audited. So we audit the first one, 80%, they get another recourse. They get another prefix. They come back for more, will audit the last allocation, because that hasn't been audited, it was recently given to them. But as the requests grows, we do the full audit of all the prefixes. But the 80% rule is aggregatable, it's just how we put it in practice. 22:14 Ernest Byaruhanga : Okay, thanks. LACNIC, we pick just one from there. LACNIC are still... There's an inter-RIR transfer proposal that's being discussed in LACNIC. I believe it is still under discussion. So this proposal allows organizations outside of the LACNIC region to transfer space into LACNIC from another registry, so that for the purposes of building more networks in LACNIC, etcetera. The way I looked at this proposal, I did not see, unless I missed something, it seems it allows only transfer of space into the LACNIC region, not out of the LACNIC region. I believe, there is a LACNIC representative here that could correct us. This we picked up, because an inter-RIR transfer proposal has come up before in our region although it was rejected. But yeah, actually two of them have come up before, and this is again of interest for those who think that this might be necessary in our region. Andrew, you have a question? 23:25 Andrew Alston: Yeah, I've just been looking. Okay, so the LAC policy specifically states that; if I wanna buy space from a LAC member, I've got to be a LAC member and I can't use it in the region. What I asked Owen just now, what the Owen thing said about space going out of the region, he said it's not in the policy but it's a staff interpretation, if you can clarify that Owen. LACNIC obviously said they can transfer space into the region. My question is, in the event of an inter-RIR transfer policy being made available that does allow for AFRINIC members to transfer space in, what is the current state of readiness to accept space and transfers like that? Have we done any planning whatsoever in our backend systems to actually allow for transfers in and out of the region? 24:25 Ernest Byaruhanga : I'll try to answer that. The last question in particular, and the answer is yes, because knowing that you pretty much know the history of AFRINIC and setup, we've actually had transfers of space from other regions including all the technical aspects that come with it from reverse DNS to sanity of checks in the Whois database, etcetera. So on the technical side, yes, I believe that we are 100% ready for that. It's the policy side that would be the issue. Owen, yes. 24:58 Owen DeLong: Owen DeLong, ARIN Advisory Council. Without getting into the murky and muddy details of staff interpretation of policy, I would let the ARIN staff represent themselves if they were here to do so. I will say that this proposal did not achieve consensus in LACNIC and was returned to the mailing list, so it's still being discussed in LACNIC and there is substantial resistance to the non-reciprocal nature of the proposal. 25:35 Ernest Byaruhanga : Thanks, Owen. Yeah, the same proposal was... Well, not the same, but a similar proposal came in our community I think about two years back and I think it was mainly rejected other than Andrew who supported it. No, just kidding. [chuckle] 25:58 Seun Ojedeji: Yeah, you have a comment on this? 26:03 Michael Graff: It's a question. 26:04 Seun Ojedeji: Okay, please state your name and your affiliation. 26:07 Michael Graff: My name is Michael Graff and I'm an AFRINIC fellow. This is a question about policy in general. It should've come at the earlier session but I was distracted, but please indulge me. The question is simply whether when the Co-Chairs recommends to the board to ratify a policy, does the Board have the power to decline to ratify it? Or are they just a rubber stamp, they have to ratify? Thank you. 26:37 Seun Ojedeji: Thank you very much for that question, I will take that. Although I see the Board Chair is coming up, but from the side of the policy and the Co-Chairs, we understand that Board has that option. Thank you. 26:54 Sunday Folayan: The board looks at the process used in arriving at that policy, and not the content in approving. We approve that the process was followed, everything is fine, and done according to the rules. 27:11 Seun Ojedeji: Yeah, Sunday, sorry. The question was whether you have the option to reject or not. And I hope my response was in sync with yours, that's just what want to confirm. 27:23 Sunday Folayan: Could you repeat your response? 27:25 Seun Ojedeji: That you have the option to reject the approval... To disapprove the recommendation of the PDP Co-Chair, or not? 27:38 Sunday Folayan: Yes. 27:38 Seun Ojedeji: Okay, thank you. [pause] 27:45 Seun Ojedeji: I think we can continue. [pause] 27:57 Ernest Byaruhanga : We picked two proposals from the APNIC region, and the first one was the modification to the criteria for getting AS numbers from APNIC. And I believe this discussion has also popped up a couple of times on our mailing list, and this is why we thought we should share this. So, this proposal at APNIC modifies the eligibility criteria for getting AS numbers such that the need to be multi-homed is removed, it's wiped out. So, currently this is the requirement to get an AS number from APNIC. I believe it is the same requirement to get an AS number from AFRINIC, and the APNIC region is considering removing this requirement. The only requirement that is going to remain is that whoever is requesting the AS number is planning to use it within six months. That's our interpretation, and if anybody from APNIC thinks we misinterpreted it, please feel free to correct us. This has come up before and this is why we're sharing it. 29:07 Ernest Byaruhanga : The second interesting proposal at APNIC also is a modification of the eligibility criteria for IPv4 space, and the proposal would extend the criteria for end site IPv4 requirements. These are the equivalent of end users in our region so that an organization can be eligible to get IPv4 space if it is currently multi-homed or interconnected with an upstream provider address space, or plans to advertise the requested space within three months. We did not read through the rest of the proposal to find out the motivation for this, but I believe one of the reasons that APNIC region perhaps could be considering proposals like this is because large allocations in the APNIC region are no longer possible anyway, since they're already in the last phase of consuming their last /8, which the last phase only allows issuance of small blocks in the first place. 30:16 Ernest Byaruhanga : So I believe they are not trying to make it not that difficult or make it easy for anybody to get a small block from APNIC, if only they show that they will be a multi-homed or if they plan to use it within a reasonably short time after getting it. The requirement to just be multi-homed has also come up in our region, and again, this is the intent of sharing these two proposals because they are similar to what has been discussed before and I believe that our folks that receive requests from members have seen arguments like this, company's saying "Hey, we just want to be a multi-homed, but we do not meet the rest of the requirements and we think we deserve to be get IPv4 space," and if you think that is the case that applies to you, that is being discussed elsewhere, maybe go through the current mechanisms to propose something similar. 31:09 Ernest Byaruhanga : So at this point, I would like to call Marco, the Policy Personnel at RIPE NCC to share with us what RIPE NCC is discussing. You're here, there's no need for me to talk about it. [pause] 31:43 Marco Schmidt: Yeah, good morning. Bonjour.