Resource Reservation for IXP 0:00:03 Barry Apudo: Good afternoon everyone. Good afternoon. 0:00:08 Barry Apudo: Good afternoon. 0:00:10 Barry Apudo: I expected we had lunch unless Chair Sunday decided [0:00:13] ____ are not eating. We ate, good. My name is Barry Apudo, I'm from Kenya Internet Exchange Point. I'm going to co-Chair this with John. We had given you guys 10 minutes and we're thinking about to start, so we'll start. The policy you're going to turn is on session three, the proposed resource reservation for Internet Exchange Point. I'm going to introduce the speaker and the co-authors of this; We have Nishal, we have Michuki and Frank Habicht [0:00:53] ____. So, Michuki is going to take over as the speaker and he has some slides to show. Michuki? You're most welcome. [background conversation] 0:01:34 Michuki Mwangi: Good afternoon. So, I would like to just quickly go through the policy as has been submitted, discussed. As indicated earlier we have not submitted any updates to the policy since it was discussed in Mauritius, and we'll get back to that in a minute. What I do know is that in this room there are quite a number of people who were not in Mauritius and have not really had a chance to look at that policy since, so hopefully we can quickly go through it. So, first and foremost is a summary of basically the issue being addressed. I think I'm in the right place. Yes. 0:02:25 Michuki Mwangi: So, this proposal basically is looking at making reservations for the peering LANs of internet exchange points which have been considered as critical infrastructures for various economies to develop, and we are looking at the issue which is happening right now, where there's exertion of IPv4 in pending for our region, and we have many countries which don't have Internet Exchange Points. And at the same time, we have Internet Exchange Points which currently only have a /24 IP address space, and are looking to grow in terms of members where they will need, in the future, to have at least more than a /24 for their peering LAN. And equally looking to address another technical issue which affects Internet Exchange Points, which is the use of the 2-byte ASN with the route servers. 0:03:28 Michuki Mwangi: So, the first part... So, that's the introduction. The second part of that is where we try to distinguish the difference between the peering LAN and the management LAN. For the peering LAN at the exchange point, this is a public IP address space that is not globally routed, and I have to insist on that. This is a very unique case for IXPs. It is not globally routed, it is only visible to those members connecting to Internet Exchange Point for various reason... And one important thing is that when you globally route this address space, you actually do expose the IXP as a transit point, and therefore exposing the members of the IXP. So, the reason why it is not globally routed is because it can be used inadvertently as a transit point to get to ISP networks. 0:04:25 Michuki Mwangi: The IXP management LAN... Prefix rather, is used for providing transit services to value added services that may be implemented at the IXP, such as DNS route servers, the web server for the IXP which has statistics for people to know what's going on at the IXP, the mail server, and so on and so forth. So, what we're looking at to do with this particular proposal is requesting... Am I going back up? I'm going... Okay. So, the other part of this proposal is talking about the BGP route servers. Basically, for ease of deployment of peering at an Internet Exchange Point we do deploy what we call route servers, and most members will come and peer with the route server to actually exchange route prefixes at the exchange point. So, one of the things that we use to deploy routing policy at the exchange point is BGP communities. 0:05:32 Michuki Mwangi: And in BGP communities, basically the form which has been widely used is where you use the ASN of the network and the ASN of the peer. So, you will have one... In this particular case, you have, [A], which will be the ASN of the IXP, and [B], the ASN of the network that is actually participating at the IXP. Now, traditionally this has always been a 2-byte ASNs, but as we all know that there has been the introduction of 4-byte ASNs, but the provision that currently exists as per the RFCs is that the size of the BGP communities has always been a 32-bit value as opposed to. It's actually a 32-bit value so we've been doing 16-bits for one ASN and 16 bit for the other ASN to fill in that particular value. 0:06:35 Michuki Mwangi: So, now with 4-byte ASNs it means that the size of that particular field for the communities has been increased so if you have a member coming to join the IXP and they have a 32-bit ASN, then they pretty much are taking the entire space, so you have no other space left to put in the values of the IXP. So that becomes difficult. 0:07:06 Michuki Mwangi: So, for it to work, there's a proposal, or actually an RFC that does extend what we call BGP community extensions, which supports a 6-byte, a 6 octet as they call it. Sorry, yeah, a 6 octet value which allows therefore to be 4-byte and 2-byte values that can actually be put in that particular field. So, this also makes it difficult if an exchange point is going to have a 32-byte ASN because members then cannot actually come in if they also have a 32-byte ASN because the field value is only 6 octets. So, there's really nothing currently in the RFCs that supports 4-byte and 4-byte ASNs in the BGP communities. [background conversation] 0:08:42 Michuki Mwangi: So in the last meeting that was held in Mauritius when this proposal was submitted, there were a couple of questions raised and we would like to address them because we have taken time to review all the questions that were raised by the community and we would like to share with you what our views are and we hope that this will help you have a better understanding of where we are coming from. 0:09:11 Michuki Mwangi: All right. So, first and foremost, if this is just a map of our region, or rather the whole world in terms of IXP's distribution, we're looking to develop, we are looking to grow our region to look something similar to what you see up in the US, in North America, and Europe. Many exchange points. That's just a snapshot of exchange points. If you look at Africa, there are very few of them. So, in our thinking, when we're proposing this policy is the white space that you're seeing there, those countries don't have exchange points. We have no control of when they will have the exchange points but they will have an exchange point. 0:10:01 Michuki Mwangi: Why am I saying this? If you think of what exchange points do, exchange points interconnect existing networks. The fact that those countries are white, does it mean there's no internet there? There is internet. There are operators. When the exchange points come into play, they are going to actually interconnect the networks that exist there. So these networks will have IPv4 address space, these networks will have 2-byte ASNs or 4-byte ASNs depending on when they ask for it. If they're currently not multi-homed or using BGP, they'll probably get 4-byte ASNs at that point in time. 0:10:50 Michuki Mwangi: So, we need to think about those countries. Equally, the countries that have exchange points as per this map at their infancy, if you will. Very few of them have more than 20 customers. So what happens when they get to 200 customers? 300 customers? And we've seen exchange points with more than 300 customers. 0:11:19 Michuki Mwangi: So, some of us, the co-authors of this proposal, Nishal, Frank, have been spending quite a bit of time to work with IXPs in building exchange points and communities to help them build the exchange points. And so, this proposal was largely influenced by the experience that we were facing when working with these communities. So, a couple of the reminders is that this policy is focusing on IXP peering LANs, which are not advertised on the internet and the BGP communities. 0:12:01 Michuki Mwangi: We are also looking at what the IETF is talking about with respect to the RFCs on BGP extended communities, what is actually available, what is actually working. And we have seen that based on the recommendations for extending BGP communities, there is really no actual implementation of BGP extended communities that would work with 4-byte ASNs, at the moment. 0:12:36 Michuki Mwangi: So, going into a number of the points raised, one issue that was raised was with respect to the use of the Soft Landing Policy. Well, it is actually a very good point to refer to. Basically, what we are looking at is... The Soft Landing Policy is looking at routable space. What we are actually looking at is IXPs, their request is very specific. We are not talking about the... We are actually looking at the non-routable space for IXPs, which means we need to safeguard that for their growth, because we have no control as to when those IXPs are going to be established in the future. We would like to be careful to note that while we may have networks already exist in those particular countries, but we have no control as to when those communities will actually come together and setup an Internet Exchange Point. 0:13:42 Michuki Mwangi: Another feedback that we received was that this actually repeats the end user policy proposal which exists within AFRINIC, and when you look at that particular request, while that state that they should be reserved IXP, address block of IXPs, what you find is that there was an attempt to reserve this address space or to provide specific address space for 196.23 for IXPs. But the End User Policy does not specifically state that this address space is for the peering LAN, it just is for IXPs. So, an IXPs have two requirements: Peering and management. So, what we've seen as a result, and I'm not sure whether this is a result, is that the 196.23 is also visible on the internet and it's not to IXPs, so it's not really address space that is specific to IXPs, because we can see it on the routing table. 0:14:56 Michuki Mwangi: Another, oh, that goes back. Another comment that we received is that we should consider adding other institutions like NRENs, like ccTLDs, and we thought it's a good idea. Actually, when we were writing this policy we reached out to the ccTLD communities and the people who actually operate ccTLDs and we thought: "It might be something worth looking at", but in discussions we realized that the request we were making was very specific, because they don't have a specific request where some of their address space is not routable. That's to start with. They don't have specific request with regards to the size of the community stream or the community value stream for the BGP, for the route servers. This is something that's very specific to IXPs. So, in that view, we felt that it would make the policy very complicated to try and ask for so many things within one policy; and, therefore, having one for IXPs that addresses these two key areas would be of value, and then, we would be happy to work with a ccTLD communities and others to try and help them develop their own policy, which addresses their key specific areas. 0:16:27 Michuki Mwangi: We also got a feedback that we should put in, a return by date. That means if the resources are not used by a certain date, it should be returned to the pool. And we thought this was quite an interesting suggestion. I mean, really, a very useful suggestion. But then we started working on what will then that date be, what will be the date, what will be the numbers that we are looking at, or when this can actually be brought back. We have no control of the time-space, because we have no significant influence in the communities and how they evolve to setup their exchange points. 0:17:07 Michuki Mwangi: So the best way for us to do is... Let's not define a time, like put an expiry date in the policy, because it may not have traction next year and the next year, but two years after that, the policy may actually gain a lot of traction. So, why don't we actually say that there is a process in place, which is the PDP process, which can actually come later and identify, "Oh, this policy is actually not being useful to the community, so we need to repeal it." And that in its own way actually is a process where a policy that has actually been proposed that is not of value to the community can actually be repealed and removed, and we no longer have the space sitting idle. 0:17:51 Michuki Mwangi: So, that's one way we thought we can actually put an end of date to the proposal, or to the policy once it's in place as opposed to putting an expiry date on the policy itself because we have no control of the factors that play out between now and then. Another point that was raised was, we should be careful about the request for ASN reservations because it may affect AFRINIC's ability to get more ASNs from the IANA, and quite frankly this was a very good point we had naturally not thought about this, and so, we actually had to discuss what's the best thing, what do we do about this? 0:18:42 Michuki Mwangi: And as the co-authors, one of us wrote to the IANA to find out how would this work and the IANA had good news for us because in their response they said that if AFRINIC actually reserves ASNs for any specific, special purpose then they will not consider those... They would actually consider those... They will not consider them as free, but they will count them as reserved which means that it does not affect in any way AFRINIC's ability to get more addresses, ASNs rather from the IANA. 0:19:25 Michuki Mwangi: So going on we have had other suggestions there were quite a number. One of them was coming from Douglas, so when I say that he had proposed some texts into the problem statement and we thought this was a really good proposal in terms of the amendments that he was making and we would definitely like to know, what the community thinks of this. We have, as the authors, have no problem with this particular problem statement, revised problem statement. It's up here and if the community feels that it actually clarifies and makes improvements to the policy, we are happy to pass it as approved, as proposed rather, so we will definitely welcome any comments on that, so if you're happy with it, we are perfectly happy with it and that's about it. Yup, that's about it. 0:20:36 Seun Ojedeji: Okay thank you very much. I will thank you for the presentation Michuki. I think you should stay closer to... Okay you could come back so either the three of you would be able to answer the questions, and the floor is now open. So as we think it should be better to actually close the second line, the middle one so we have just back and front so that it's easier to manage that way. So we start from the front, first person. 0:21:27 Jan Zorz: Hello. 0:21:28 Seun Ojedeji: So we'll take your comments and then we'll get response. Just go ahead. 0:21:32 Jan Zorz: Jan Zorz, random member of random community around the world. I think this proposal makes perfect sense. I fully support it. If the similar thing was done all around the world and I think there is no much discussion needed, it just makes sense. Thank you. 0:21:52 Douglas Onyango: Douglas Onyango. 0:21:54 Barry Apudo: Douglas wait. We'll go to the back first. [pause] 0:22:17 Barry Apudo: Okay, just before Christian, just before you come for a comment. Ian we have a question for you. What do you mean when you say all around the world? Is it all over the registry or just... [pause] 0:22:38 Jan Zorz: There is similar discussion in other communities. We accepted something similar in RIPE region and it just, it makes sense. Because we need to have something for the IXPs to be created, and so, we are actually able to create a new IXP, so I don't see any downside of doing this. 0:23:08 Barry Apudo: So basically it's a discussion that is ongoing? 0:23:12 Jan Zorz: Similar or behind the scenes or public, but yeah, it's going on. 0:23:18 Barry Apudo: Okay, noted. Yes Christian? 0:23:20 Christian Bope: Okay, Christian will be speaking on my own capacity. First of all I like the last comment from Michuki which say that he is open for any modification based on the discussion we'll have in this meeting. Commenting on the same logic, I think I have just some suggestion is basically, technical.......... [pause]ии. 0:24:09 Christian Bope: To raise this, the reference... The RFC you referenced in your policy, the RFC 5668. If I follow the AFRINIC... There have been in AFRINIC policy AFPUB-2005-ASN-001, the policy say that AFRINIC doesn't have 2-byte ASN. I don't know if an AFRINIC staff is here, can give us more details about that, just to make sure that we are at the same level of discussion. Thank you. 0:24:52 Barry Apudo: Just a second Douglas, Ernest needs to react to that. 0:24:57 Ernest Byaruhanga: Could you please repeat the question and the request, Christian, so that we note it down and provide the information precisely as you requested. 0:25:05 Christian Bope: Yeah, because in the policy they are requesting 2-byte ASN, but if after reading the policy, it doesn't mentioned AFRINIC ____ 2-byte ASN. I don't know if AFRINIC can give us more details about that, and I will come up with my next comment. Thank you. 0:25:29 Ernest Byaruhanga: Okay. To quickly clarify you on that, I believe Madhvi will correct me if I'm wrong, but right now the wording in most of the RIR policies is that there is no differentiation between the previously called 2-byte and 4-byte AS Numbers. It's one large 4-byte AS Number pool. So, I believe the authors wanted to mean the previous lower byte AS Numbers, not necessarily 2-byte AS Numbers. Maybe the authors could just clarify that, I guess that's what you wanted to know. 0:26:00 Christian Bope: Yeah, I think it's better for them to clarify. 0:26:04 Barry Apudo: So, Christian are you done? So... 0:26:07 Christian Bope: Maybe I can come later. 0:26:09 Barry Apudo: Yes, go back in the line. So, the authors will give a comment on the two comments which have been given, before Douglas makes his comment. 0:26:19 Frank Habitch: Okay, first to Ern thanks for your comments and support. I can talk for one of my co... Or first, we have been contacted by somebody from your region who wants to incorporate or maybe it's already an active proposal. About the AS Numbers, of course they are all 4-byte, but we refer to the ones below 65,536. Anything else? 0:26:48 Michuki Mwangi: I was just looking at the minutes of the last meeting, and there was a clarification given by AFRINIC which states that although the policy is in place, RIRs have distinctively divided the 32-bit pool into three categories. That is, 16-bit only, 32-bit only, and 32-bit. And that these policies would seem to touch on the 16-bit only pool which is 0 to 65,536. That is in the minutes, I was not there and I had connectivity issues, so I'm presuming that if that's the case, then our policy will be touching on the 16-bit pool. 0:27:37 Barry Apudo: So we are confirming what's in the minutes. [background conversation] 0:27:44 S?: He's reading from the AFRINIC website. 0:27:51 Barry Apudo: As you double check it, Ernest on the minutes. Douglas, please? 0:27:56 Douglas Onyango: Thank you. I think I would like to voice my support for the fact that IXPs should be able to request and be granted resources whether they want it for peering or management networks. However, I think I'm opposed to the idea of a particular reservation at AFRINIC for this particular purpose, and this is because I think by the time... You say you want to have these resources for such a time as when we don't have IPv4 space to give out, and you still want for the exchange points to be able to have access to these resources. 0:28:43 Douglas Onyango: My argument is as follows: When there is no IPv4 to go around, a lot of the internet could have moved to v6 or whatever it is they want to move to, and that in by extension means there would be not so much for the IXPs to want to connect to other point in time. So, the need for a v4 reservation from AFRINIC doesn't look to me like something that makes a lot of sense. Thank you. 0:29:17 Barry Apudo: Yes, Owen. 0:29:18 Owen DeLong: Owen DeLong, Akamai ARIN AC. I'm going to respectfully disagree with Douglas' previous comment. In the ARIN region we had a policy which reserved a /16 for IXPs and DNS infrastructure for top level domains for many years. We recently updated that policy, we took out the... Or excluded the new gTLDs from the reservation because we felt that that would consume things far too quickly, and we expanded it from a 16 to a 15, essentially doubling the amount of space available, because as was mentioned by Michuki, exchange points connect existing operations. 0:30:09 Owen DeLong: So the need to build out additional exchange points and increase peering density over many years after v4 went out will continue even as v4 starts to dissipate off of the internet, and believe me that cannot happen soon enough for me. We will still need to have v4 for exchange points and I think reserving v4 in the AFRINIC free pool for that purpose is wise and far-sided and that we should just do it. 0:30:42 Barry Apudo: So just before the next person online gives his comment, I'd like to get reaction from the authors. 0:30:51 Michuki Mwangi: Okay, so I think I would like to echo. If you look at the map that I presented, we have no control, Douglas, of when those countries will come online, and those countries have operating networks today. They're mobile operators on 3G, they're mobile... They're country incumbent telcos which are giving fixed-line connectivities. So when the exchange point comes in, it is there to connect existing networks, not new networks. Not new networks, existing networks. And remember you need at least three to call it an Internet Exchange Point. So these are three existing networks. 0:31:32 Michuki Mwangi: So if the IXP does not have v4 but these networks that it wants to interconnect have v4, what does it do? So it is critical that when the exchange point comes into... Is created, it is able to connect both legacy networks on the networks... I mean, a legacy network is the wrong term to use but ideally I hope that sort of sends the message. But legacy networks and the new networks, it needs to connect both. Thank you. 0:32:10 Frank Habitch: This is probably a good time to add that, the three co-authors office here in front... We operate exchange points but we have the resources that we need already, we don't do this for our exchange points. We are thinking about the future five or ten years ahead if in the country that hasn't have anything they would start up an exchange. And I have a question for Douglas if I may, you said you are against this particular reservation for this particular cause. Did you mean it to be a wider cause would be fine, or any reservation would be bad? And as a response we have left the door open in that the PDP can always remove that policy at all at any time when it's deemed to be expired. 0:33:02 Barry Apudo: Yes, Kevin. 0:33:03 Barry Apudo: Reaction from Douglas? Before... 0:33:11 Douglas Onyango: And by cause I meant we want to call only the IXP's critical infrastructure. Now we have other pieces of set-ups that could be called critical infrastructure and if you would like to reserve, make reservations of critical infrastructure, we need to try and accommodate fairly what we call critical infrastructure which is now a way to open up debating to other matters and that is where I'm coming from with my argument. Thank you. 0:33:45 Nishal Goburdhan: Hi Douglas, it's Nishal. Just to make one thing clear, and I don't intend for this to become a technical argument, the two very specific requirements that internet exchange points have that other pieces of critical infrastructure as defined or not defined by policy in this or any other region may or may not have. We need the address space that's not routable at across the internet, and Michuki's explained that already, and there's a requirement for the ASN that's used to be the 2-byte ASN. So yes, it's absolutely possible to reserve address space for, just about anything else that you'd want, somebody decides that NREN's a critical infrastructure and then policy gets passed for that, but they do not need a policy requirement for non-routable address base, for example, or specifically a 2-byte ASN, so the 2-byte AS thing is a very unique, very specific thing. 0:34:40 Nishal Goburdhan: Again, tied not just to exchange points and Michuki explained the two networks, but to the BGP route server, at the exchange point. We feel that the distinction was important enough, as Michuki said at the start, which is why we would prefer this and why we wrote this up to be only about internet exchange points and not to include a ccTLDs or anybody else. Although we're open to assisting them if needed. 0:35:11 Barry Apudo: Kevin, go ahead. 0:35:12 Kevin Chege: Thank you. My name is Kevin Chege, I'm a member of the community, I was at the last meeting where this was presented and I was supporting and I was hoping that the NREN's would be included as part of the proposal, but I can understand that this would introduce complexities, so I would like to voice my support for the proposal as is, and I'm hoping for the NREN something similar can be drawn up in the future. Thank you. 0:35:43 Barry Apudo: Yes prof? 0:35:45 Nii Quaynor: Okay, I think I heard someone say a similar policy as this in the RIPE region, can we have a reference to it so that at least we can be at par? That's one. Two, I think we probably should fix the document to reflect what we seem to have agreed, that is we have only 4-byte registry and you're choosing a certain particular map. So we are doing 4-bytes, map about 2-bytes, so we are making sure that their left side has zero. Have it reflected in the document to be healthy. Because that's all we have, we only have one registry and it happens to be 4-byte so we should fix that. 0:36:34 Nii Quaynor: Under reservations, somehow I would prefer, we solve it holistically and perhaps do it with modification or enhancement of the Soft Landing Policy. Okay, meaning first we've dealt with the ASN then next we are looking at reserving the force. So something about it strikes me that it may be better to deal with all of it including the critical infrastructures, reserve them the way you want it because we really think you should get all the resources you need, but we like to do it in a holistic way without looking at allocating by nations and so on and so forth, but do it holistically to whatever your requirements are. 0:37:27 Nii Quaynor: That way then, it is like fixing something we should have done earlier with the soft landing and then it would serve everybody's interest. I want you to have it. Meaning in my opinion we want IX Exchange Points to thrive, but we want them to thrive because some countries need many more, some need little, but at the same time we want to make sure that any allocations you need you are able to get, but also serve the needs of all the other critical infrastructure and do it by one method as opposed to solve one bit and then another bit later. That's just my preference. 0:38:08 Nii Quaynor: So, if you're willing to work with us on that, we can perhaps come up with another policy which is more encompassing and addresses all the critical infrastructure needs as well as needs of new comers because new comers may also need some force to be able to go to the other places and so on and so forth, so that's what I thought I would add to your work, thanks. 0:38:36 Barry Apudo: Before we get a reaction from the co-authors we'll take his comment and then get a reaction. 0:38:43 Arnaud : Okay. Merci 0:38:44 Arnaud: Thank you. I would like to switch to French. Thank you. I agree with this proposal it's okay, but I would like, with the control of the technical team of AFRINIC, one of your concern in the feedback you sent in number two, your concern is the non-application of the ASN adopted. You said because they are not routable? Can I continue? Says the speaker. I would like to know whether isn't it possible to make the ASN adopted non-routable by the AFRINIC team so this is the proposal I'd like to bring to your feedback number two concerning the non-routability of the ASN. 0:39:58 Barry Apudo: I request the guys on the queue please keep it brief, the queue is getting longer and longer. Keep it brief. So before Mark you give your comment, the co-authors will react. 0:40:13 Frank Habitch: Okay, about the last speaker, sorry I only got the second task. About non-routability it refers to the IP addresses, not the ASN. [background conversation] 0:40:33 Frank Habitch: So IXP's definitely do want IP addresses not to be routable because if they would be, specifically the IP addresses used on the peering LAN of the IXP because if routable, these could, and these were in fact in the past used for DDoS attacks, vulnerability attacks against certain peers at the internet exchange. There was a big thing about Spamhaus in March 2013 for instance on internet exchange, that's a good one. So they should not be routable and AFRINIC should not do anything, they should not make them routable or non-routable, they should just provide them, but publicise that these are from a certain block and this block is really dedicated to this purpose. That's what we are asking for. 0:41:38 Michuki Mwangi: So there was a comment from Doc and, actually two comments. So, as we've mentioned, we definitely made an attempt at looking at this holistically, but one thing that became very clear to us is that, looking at this holistically means, it will be a very long and complicated policy proposal because we are looking at the detail of what are the issues. For the IXPs, right now, it is very clear to us we have a non-routable space, which we need and we have the requests for the 2-byte ASNs for the route servers. So those are very specific to the IX. Now, on top of these, if you are to deal with the ccTLD, the ccTLD will come with its own requests. I don't know what that would be, but they may have their own. If we have an NREN, the same. 0:42:40 Michuki Mwangi: So it would be a very, very detailed document, which we thought will be very complicated and, it will complicate the process. So it's easier to discuss the IXP and have it over and done with. If the ccTLD have theirs, they can actually do the same and they make their proposals for their reservations and if you think about it, if you're making a request for reservations, here it's very clear why we are asking for a /16 and why we are asking for 114 for 2-byte ASNs because we are anticipating this is just as far much as we would need in terms of IXPs in terms of the space within the foreseeable future of the policy. If at a time comes when we feel that there is a need and there is much more demand than we anticipated, then that can be increased, but it will be specific. 0:43:40 Michuki Mwangi: If you have a holistic proposal, it means that for the IXP part, do you go and specifically increase for the IXPs or for the whole proposal? So having this granular approach in terms of looking for the IXP specifically, in our view helps us address the key issues for each particular groups as opposed to having a whole, a unified proposal that goes into... Looks at each one of them in details, that splitting or rather the differentiation will be very difficult. That's one. 0:44:17 Michuki Mwangi: On the 4-byte registry, I would definitely like to hear more from AFRINIC in terms of what... And I looked at the minutes of what was published in Mauritius. I was... What I was reading earlier, AFRINIC noted that although the policy is in place, RIRs have distinctively divided the 32-bit pool into three categories. So I'm reading that directly from the AFRINIC website on the minutes. So it will be good if someone from AFRINIC can actually come on the floor and clarify what is actually going on and then we can actually review our proposal to reflect what is the practice or what is the accepted practice within AFRINIC. [background conversation] 0:45:17 Michuki Mwangi: Okay. And we have found that the document that is being discussed at RIPE has been shared with the policy Chair and co-Chair so they can share that with you. Okay, Madhvi, please you can proceed. 0:45:35 Madhvi Gokool: Yes, I Madhvi, Registration Services Manager. I did not check the minutes, but by hearing the conversation about the three categories, there is a policy for the 4-byte ASN that was proposed by Jeff Houston in our region and in there, the terminology that is used by him is 2-byte only AS Numbers are the ASNs in the range of 0 to 65,535, 4-byte only AS Numbers, those would be in the range 1.0 to 65535.65535 and 4-byte AS Numbers ranging from 0 to 65535.65535. So as per that policy, as from the 1st of January 2010, AFRINIC ceased to make any distinction between a 2-byte only AS Number and the 4-byte only AS Number. That's how we implemented this policy. So yes, we need to... There hasn't been a shift in stopping to use 2-byte and 4-byte, but the other way of stating it is smaller and bigger. 0:47:00 Madhvi Gokool: So, when we started implementing... When we implemented this policy, we stopped making the distinction, but operationally, we were still issuing from the smaller pool that we had because we were issuing from there. The larger pool was basically not being utilized at that time, so we carried on issuing from the smaller pool and then decided to shift to the bigger pool. 0:47:33 Madhvi Gokool: Okay, so right at the moment, we issuing from the bigger pool because all the AS Numbers that we have from IANA, form part of one single pool of AS Numbers. So provisioning it, it can be a bigger one, it can be a smaller one. Alright, so we do not make the difference. It's just if we want to issue from a bigger pool we issue it, because it's available. Okay? That's how we're doing it, so I don't know... 0:48:09 Michuki Mwangi: So, is there request for this particular policy to refer to 2-byte ASN out of place, or out of order, if you will? 0:48:24 Madhvi Gokool: If you mention 2-byte, you may be in contradiction with this, or if you say smaller or within this range, then it... 0:48:35 Michuki Mwangi: So, if we specify the range. 0:48:37 Madhvi Gokool: The range, then it would be... Because, otherwise, you would get what was previously known as the 4-byte, the longer ones, the bigger ones. 0:48:51 Michuki Mwangi: Okay. Alan looks like, "I don't want to take over the model." 0:48:56 Michuki Mwangi: Okay. 0:48:57 Barry Apudo: I think that's clear to the core that's what they need to do. Thanks, Madhvi for that. Next on line, please. Let's keep it brief the queue is growing, it's really long, let's keep it brief. 0:49:11 Mark Elkins: Hello, this is Mark Elkins. I really like this policy, I'd like to support my name behind supporting this policy. The critical aspect of this particular policy is in fact the reservation of 2-byte ASNs. So, I did some research, you're asking for 114 minimum and there are a 174 of these 2-byte ASNs left in AFRINIC, which are deemed to be clean, and there's another nine which has obviously been returned or something are deemed to be dirty, so you get a 174 clean ones. 0:49:50 Mark Elkins: I believe it is very critical to do this because of the 6-byte ASN issue when exchanging at an exchange point. And this is important because all new people coming in to the game would probably end up with a 4-byte ASN. So, if the exchange point has a 4-byte ASN, then things are not going to work properly. I also think keeping this policy separate from ccTLDs and other things makes a lot of sense because I don't believe that these other critical infrastructures need to worry about 2-byte or 4-byte ASNs. 0:50:38 Mark Elkins: From a view point of the address space, really that's a non-issue, we've got plenty of IPv4 address space. So, I don't see what's wrong with reserving that is not gonna upset anyone. We need to burn through that anyway. The critical part about this particular policy is in fact securing the 2-byte ASNs and I do applaud you for looking at this in a technical aspect like this to make sure that we in fact have room for another 174 exchange points. Thank you very much. 0:51:13 Barry Apudo: Yes, doctor. 0:51:18 Paulos Nyirenda: Thank you, Paulos Nyirenda from Malawi. Maybe three issues I wanted to raise having just [0:51:28] ____ the experience, I was going to ask about 2-byte, 4-byte because we did experience this recently on our exchange point with a fact that one of our members was asking specifically for an ASN to get full use on the exchange point and he was issued a 4-byte ASN, and it cost us quite a bit of hassle because he was not willing to go back to AFRINIC to get a new one. And finally they did issue a new one. 0:52:05 Paulos Nyirenda: I have reservations on this reservations policy because of a big issue of definition for critical internet infrastructure. I really do think that DNS is critical internet infrastructure and I think an earlier speaker already indicated that in other regions, the reservation policy does include, had a critical internet infrastructure including TLDs, where ccTLDs are a sub-sector. 0:52:46 Paulos Nyirenda: So, I'm unhappy with the policy that it doesn't go far enough to include genuinely critical internet infrastructure. And I think if you plot the maps, if you re-plot the maps for IXPs and put ccTLDs on top, you'll see that the picture is small as this, and with the way that the ccTLDs are, and the distribution of IXPs. 0:53:14 Paulos Nyirenda: Finally, I would like to raise the issue of access to the reserved space. How this access would be managed and access includes price? And so, if I have an IXP and I want a second /24 from the reserve, I would like to see in the policy how this is accessed by my IXP. Would I have to pay for it? 0:53:44 Barry Apudo: I'll get the second, the other person on the line before, I'm seeing the co-authors are eager here to react to Paulos. Sorry... Yes, we change the policy to three, so your comments first. 0:53:58 Serge Illunga: Okay. ____ I will speak in French. So my name is Serge from GR Com [0:54:06] ____. 0:54:06 Serge Illunga: I'm from Congo. What I wanted to say is that I support the fact that the exchange points play an important role in Africa and that it is the responsibility of the community to ensure the availability of the necessary resources for this development, but by looking at the different AFRINIC policies, we see that there is a landing policy. My question is, why not... We have not reassured the preservation of these necessary resources in the application of this policy? 0:54:54 Barry Apudo: So I'll get the reaction from the authors on the three comments that have been made on the floor. Frank? 0:55:06 Frank Habitch: Okay, thank you, Mark... Thanks to Dr. Paulos. We strongly believe that the requirements for IXPs are unique in regard for these resources that we have requested and the IXPs... There will still be more IXPs coming up in Africa and elsewhere and we don't see that the case for ccTLDs because there's a finite number of countries. [background conversation] 0:55:48 Michuki Mwangi: Okay, so I appreciate the concerns that Dr. Paulos has brought on with respect to the... When we map up the ccTLDs and I think what he was referring to is when you map the ones that are actually operated in region, the map will look more or less similar to what we have with the IXPs. So again, we have two distinct requirements, Dr. Paulos. One of them is that the reservation we are requesting for is a continuous block for IP address space that everyone we know, whenever you've seen this, because it's going to be published, you will know that it's for IXPs peering LAN. Secondly, we are asking for ASNs, 2-byte ASNs. 0:56:51 Michuki Mwangi: Sorry, I have to clarify, yes. The smaller numbers below 65536. If that's the case, we found it difficult and I think we've had a couple of exchanges with some of the ccTLD operators that we know and we found that their requirements were going to be outside of this scope, which is what this particular policy is trying to focus on. We are not trying to redefine the definition of critical internet infrastructure. We are trying to define the requirements of an Internet Exchange Point, which is different and that's why we were left... 0:57:42 Michuki Mwangi: We really tried to see how we could accommodate because before we brought it even to the AFRINIC meeting, we did discuss to the ccTLD managers that we have contact with and we realized that we would then be writing a policy that first redefines critical internet infrastructure to make the reservations, but what we are trying to achieve is address a critical need... A critical function of the IXP and some of the challenges we're facing and making sure that is well catered for, and then, there's no limit in terms of us coming up immediately after this meeting and having a document that actually redefines critical internet infrastructure and what their requirements and reservations would be. 0:58:33 Michuki Mwangi: I don't see that being a limit, so I would encourage you to not have reservations on this particular policy, but have reservations, that there's no critical internet infrastructure policy that aims to reserve resources for that particular group of organizations or functions of the internet. So I hope that sort of clarifies our position on this. Thank you. [background conversation] 0:59:07 Nishal Goburdhan: To answer the last part of your question, Dr. Paulos, you wanted to know at what rate and how these get allocated? We do not make a distinction on what an Internet Exchange Point is or how AFRINIC allocates to those. That's something we've been actually asking from AFRINIC for about two months now without an answer. Madhvi is nodding her head, but I'm sure she will get it to us. 0:59:29 Nishal Goburdhan: We believe the RIR does a very good job of doing that. They have processes and policies in place to deal with what actually is an Internet Exchange Point and how to make reservations for that and our goal is not to interfere in their process at all, nor is it our goal on how to set costs attached to that. I think that's what the board is supposed to do and I'm looking at some board members and they're nodding at me. So we're going to leave that to the board. 0:59:55 Nishal Goburdhan: What we like as Michuki says, is just to be able to distinguish that there is a particular need for Internet Exchange Point resources in the manner that my colleagues have been talking about, and we're looking to get a reservation for that. And to add a clarification, in other regions it's not necessarily tied into the same pool. So, for example, the RIPE region, the document that I have sent to Ernest and the co-Chair here, speaks specifically about exclusive Internet Exchange Point peering LAN use. So, there is... If you're looking for it, there is precedence set, we don't really care about the precedent to be honest because we're doing what we think is right for our region and we're asking you for your support. 1:00:37 Nishal Goburdhan: The other last point that I wanted to make was that, in Djibouti there was a policy, I think it was Djibouti, there was a policy that was voted down about NRENs, and one of the messages that came from this community, was that the policy authors didn't run an NREN and didn't know what was good for an NREN. So, while we know about internet exchange points, I run three, Michuki runs two, Frank runs one and a half, we think we know what makes an Internet Exchange Point work. I can't say that I can speak with the same measure of authority for what would drive the ccTLD. I have a good amount, fair amount of common sense, I think, and I can design and build your network for you, but I'm not an authority on that. So we stuck to what we know about... 1:01:28 Michuki Mwangi: There was another comment on the Soft Landing Policy and I have to say that my previous comments also sort of... We're still focusing... We're avoiding to put this together with everything else for those very two specific reasons. And we're not very sure how... I mean whether we're going to have... It's more likely we're going to have unintended consequences as a result of bundling this into another policy because then people will get confused as to why we're asking for this number inside a larger policy and so on and so forth. So, that's why we're really, very particular and very... It would appear insistent that this is very specific to IXPs and not to the whole of the routable space or the whole IPv4 space that is available to be reserved under the Soft Landing Policy. So, it's very, very specific. I hope Serge that sort of answers your question. Thank you. 1:02:39 Barry Apudo: Just a clarification for the authors. Nishal that, the URL you've sent you can actually send to the PDP list for everybody to see. Yes, please? 1:02:53 Christian Bope: Yeah, thank you, Christian Bope from DRC Congo. I think we are almost reaching the convergence point. Following AFRINIC's staff comments concerning the ASN 4-bytes, I think the first condition which comes to my mind is, we should first of all remove the reference to the RFC 5668 because the RFC 5668 in the global F4-byte and the local F2-byte. Following the discussion we cannot use that as a reference, otherwise maybe, because in our case we will have something like four four, which means that we need to go to ITF to... It will be a very, very long process. 1:03:41 Christian Bope: Having said that, I think also we need to avoid breaking our own policies because we always have a policy as Madhvi explained, and maybe I will make a suggestion, what do you think if just maybe in the AS Number list you choose the range which can be used for your exchange points, maybe it could be also an option? In order... Because what I'm saying is AFRINIC staff, maybe AFRINIC can maybe propose a range and in the range you chose maybe, I don't know, it's just something coming to my mind, maybe together we discuss on it in detail to find out we can make it happen. Thank you. 1:04:27 Barry Apudo: That's noted Christian... Noted... Please? 1:04:33 Edwards: Good afternoon everyone. My name is Edwards from NFT Consult, Uganda. My question asks for more enlightenment. What is AFRINIC's current policy for reserving /16 IPv4 resources to Internet Exchange Point? 1:04:56 Barry Apudo: Ernest? 1:05:00 Ernest Byaruhanga: Could you repeat the question please? 1:05:03 Edwards: What is AFRINIC's current policy for reserving /16 IPv4 resources to internet exchange points? 1:05:14 Ernest Byaruhanga: There is no such policy for reserving blocks of resources for IXPs. I guess that's the spirit of this proposal that we're discussing. 1:05:26 Edwards: Okay, thank you very much. 1:05:33 Barry Apudo: Yes, please. 1:05:34 Marco Schmidt: Yeah, Marco Schmidt, RIPE NCC. I just want to respond quickly to previous questions for the exact reference in the RIPE region that we also have similar policy. And it's in the IPv4 policy, so it's in RIPE document 643 and there we have one section 6.1 that defines, you probably know that's... You can get starting from /24 up to /22 IPv4. And is strictly restricted to the peering LAN, and we don't have any reservation of 2-byte ASN, so just IPv4 /16. 1:06:11 Barry Apudo: Thank you very much. That's noted. We'll have Owen and Doc. If at all there's any comment, I think we'll give you two minutes to decide if you're coming online, otherwise we draw a ____ red tape. Owen, please. 1:06:29 Owen DeLong: Owen DeLong, ARIN AC and Akamai. Bikeshedding this proposal into some sort of be-all end-all solution to all the world's problems is not a good idea. The authors have expressed clear reasons for doing this as an Internet Exchange Point policy only. Those are good reasons. People that want a proposal to cover DNS should propose one. They shouldn't try to sabotage this one because it doesn't happen to be the proposal they want for an unrelated matter, where the only similarity between the two proposals is they contain the word "reservation." 1:07:10 Owen DeLong So, let's stop bikeshedding this, let's get it moving forward, let's get it done, and if the DNS operators want to do something for DNS, then let them bring it before the community, and let the community consider it. There is no reason to hold this up. I'm not sure I understand the reason that exchange points uniquely need short AS Numbers. A lot of exchange points I know are working just fine with 4-byte AS Numbers, and so, I don't know why that is, but whatever. I don't really care. The proposal is a good one, move it forward. 1:07:52 Barry Apudo: Yes, Doc. Then we'll have comments from the authors. 1:07:56 Nii Quaynor: Thank you Mr. Chair. I think what I heard was that RIPE exchange point policy does not cover ASN's. Did I hear correct? 1:08:10 Barry Apudo: Yes, you did. 1:08:13 Nii Quaynor: Okay. I hear ARIN doesn't either. So this is where I want to make a proposal. Separate the two, okay? And we can write the ASN differently, because you seem to have arrived at some way of describing that in an acceptable way, by saying smaller ASN. So that means that part, we don't have a problem in dealing with. And the other RIRs, are not really having a policy of that nature, so that's why I'm proposing that you bifurcate it, separate it. The second thing is then the IPv4 area, it would normally not be an issue, except for the fact that we are in the adjusting phase, right? It's getting finished. That's why this becomes an issue. Okay? 1:09:05 Nii Quaynor: And hence, instead of just giving a first come, first serve, reservation, reservation, reservation... Someone who is saying it might pay to take a look at the needs some of the clearly identifiable critical resources, and then do a policy for them. You know what I'm saying? You can take the ASN as you want it and move on, but because this other one has become a pressing something, something that was getting finished, and you are concerned, and you may not be able to have it to do the things you want, and similarly the other groups who are saying the same thing. Then we probably can look at it and by November have a policy. This is what I think I will suggest. I hope it helps you. We move forward on one, the other one you work with the community and you get something then we work. Thank you. 1:09:56 Barry Apudo: Thank you, Doc. So, I'll get comment from the authors as Ernest looks if there's comments from the remote participation. Are there any comments from remote participation? While they're waiting. 1:10:19 Michuki Mwangi: So, one of the challenges that does and I would understand why that there is no particular policy on ASN's in Europe or in RIPE NCC region or ARIN is... And no, I haven't done any survey or anything of that nature, is that the use of route servers at IXP's is fairly limited in Europe and North America. There's a lot more of bilateral peering that takes place, which then this particular request may not be about significant issue. 1:11:04 Michuki Mwangi: In our region, the use of route servers is almost like a default in terms of most people prefer to peer with a route server, we've been known to be the ones that have actually had some of the peering, like Mandatory Multi-lateral Peering Policies and Multi-lateral Peering Policies where we use the route server to force everyone to peer the exchange point. 1:11:30 Michuki Mwangi: And so, the use of route servers is more prevalent in our region compared to others, and as a result, we and I think Dr. Paulos comment in terms of how they had to face this is evident in the fact that most of the exchange points that we have tried to deploy, we have deployed, or we have worked with too have route servers, and so, in dropping the ASN issue means that we have to then go back to... To try to find another way to deal with the issue. And at this point in time, the option that really exists, is having the protocol work done to actually have an RFC for this and that's a much much longer path to go through the IETF to have this result. So I'm not sure whether I am understanding the comments, but my view is that... These two things are... Yes Doc. 1:12:40 Nii Quaynor: I think you may have misunderstood me. I was actually saying that for the ASN, you found a solution. 1:12:47 Michuki Mwangi: Yes. 1:12:47 Nii Quaynor: So take it and go. I'm not saying you shouldn't have it, I'm saying you've got one, take it, run. And then the second half we fix. That's where I was trying to come, I hope you hear me. Meaning that you don't have a problem with the other regional registries, they are not doing it. 1:13:02: Michuki Mwangi:Yes. 1:13:03 Nii Quaynor: You say you'd do it and they say they have a solution. You can take the smaller numbers and go. 1:13:08 Michuki Mwangi: Alright. So then in that case, we are happy to revise the text to refer to shorter numbers so any thing lower than 65,536, and any other editorials that we will get and resubmit this to the list. [background conversation] 1:14:37 Seun Ojedeji: Okay. Thank you very much for all those that have contributed. And sorry for taking time, we've taken so much time on this and it's... I hope you will all agree with me that it is worth it. Myself and my colleague, we have been discussing way forward on this particular policy proposal. What we understand is that the authors are willing to make the necessary change as it concerns the six... As it concerns the ASN. If there is any reservation for that based on this, the suggested change, it will be good for us to hear that now especially on the ASN. 1:15:45 Seun Ojedeji: On the prefix, we've observed that there has been a lot of here and there discussion about the prefix. The reservation itself and we are the... We like to... We are wondering whether there is any objections specifically on this prefix? We have observed a few objections, but we have also observed a lot of support as well. However, we all know that the process is based on consensus and we'll like you to make our job easier from this place. So... [pause] 1:17:00 Seun Ojedeji: So we... Owen want to say something? 1:17:05 Owen De Long: I wanted to make a suggestion that perhaps calling for a show of hands for those who would support adopting the policy is written versus those who think it should be returned to the mailing list. [applause] 1:17:23 Seun Ojedeji: Yeah, thank you. [pause] [background conversation] 1:18:31 Seun Ojedeji: Okay. Thank you for that suggestion, Owen. Yeah, so based on the current status of things, it should be good to observe consensus on this particular proposal if there are people who think... Who are confident that this proposal should go as it is currently... Currently, can I see a show of hand? [background conversation] 1:19:31 Seun Ojedeji: : Yeah, the editorial, we've already talked about that which is that's to do with 2-bytes clarification. You wanna say something? 1:19:40 Vymala Thuron: There's a comment from Graham remotely, so I'm going to read it, "I think that it is important to move this forward, I agree with other commenters that there are other infrastructures that deserve reservation of numbering resources, that is likely to get support from myself and others, but should not be a reason to stall or hijack this policy." 1:20:14 Seun Ojedeji: If I get that's right, I think that is a support. 1:20:17 Seun Ojedeji: Support? 1:20:18 Seun Ojedeji: Yeah. Okay, that's a support. Anything? [background conversation] 1:20:26 Christian Bope: I maybe wrong, but my understanding is in principle, the majority agree with the policy and what we are saying is we ask the author to do some updates and we'll... 1:20:38 Seun Ojedeji: Yeah, so the updates, we'll have them to do is, which they have agreed to is the ASN correction, right? 1:20:44 Christian Bope: Yes. 1:20:45: Seun Ojedeji :So I believe you've agreed to doing that? 1:20:49 Christian Bope: And for what are we voting for? 1:20:51 Seun Ojedeji: So we're gonna vote for... Based, okay, let me modify, that's based on the edits, subject to the implementation of the proposed editing. Do we have any reservation? 1:21:05 Christian Bope: Yeah, our question is why don't you wait for the edit and we vote on the final ones, instead of voting on something they will edit after? 1:21:12 Seun Ojedeji: Yeah, just a minute. We know that we allow... We understand that there is a process... The process is that if this move is... Actually, is not the approval, it's not the final approval, it's still going to go to last call and then you will still have the opportunity to see the drafts as it is, and then you will be able to make comment with same proposals that actually, going back to the list from the last call. Sorry, Andrew, that could be one of... That is the fact. We could actually still discuss this on the mailing list and then the timing, especially if the authors did not implement the changes as proposed. So I hope that clarifies your view. Christian? Okay. 1:22:19 Paulos Nyirenda: Similar concern. Paulos Nyirenda from Malawi. I don't think there should be a vote. The PDP does not define a vote for policies, so I really... It only defines consensus, and at the moment, I think it's inappropriate to take a vote. 1:22:39 Seun Ojedeji: Point of order. Did I mention vote? If I did please, I stand to be corrected. My intention was to observe consensus by show of hand. 1:22:52 Sunday Folayan: Sunday Folayan, Nigeria, ccTLD. I don't know how the Chair would observe consensus without asking for a show of hands to gauge if there is consensus. So definitely, gauging consensus is not the same as taking the votes. Having said that, I want to say as a ccTLD, we support the proposal when the other people need to do things that would bring their own proposal and to also see that the minutes would adequately reflect what changes I expected to be put into the policy. Therefore, trying to stall the policy moving forward by saying that we should come back another time is a waste of the time of this community. Thank you. 1:23:47 Seun Ojedeji: Thank you. [applause] 1:23:52 Vymala Thuron: I have got other comments. So Patrick Okui, Ugandan Internet user, supports the policy. Phil Regner, Kenyan user support those proposal as it, Graham Beneke, South Africa, supporting the policy, and ____ Bihana from Gabon, too. Thank you. 1:24:12 Seun Ojedeji: Andrew, is he still in support? 1:24:15 Andrew Alston: Chair, first of all, yes, I support it, but I also want to second what Sunday has said, and I also point out that there is plenty of precedent going back over the last couple of years for policies to... For a show of hands to be taken to gauge consensus on policies based on amendments that have agreed to, been agreed to and will be applied on once the consensus is shown. So there is plenty of precedent and I really do not like the fact that we are looking at a situation where people want to delay this by six months purely because they haven't seen amendments written that have already been agreed to. It's bizarre. 1:24:56 Seun Ojedeji: Yeah, thank you very much Andrew. I think I've... We've already clarified that and then we can move on I think. Thank you. Christian, do you have a final word? 1:25:08 Christian Bope: Yeah, just a comment, because I don't accept the fact that someone is saying we're wasting our time, because this policy where we discussed in Mauritius, there was no updates, and we're said to discuss again. Which means that we're not wasting our time, and if you compare the debate today and the Mauritius debate we made a lot of progress which means that... As I said in my last comment, ____ to get to the convergence point, and I think we have made a lot of progress, and some of the last comment is coming is trying to break the consensus we're always trying to build on. I think... I don't know, but this is just my last comment, thank you. 1:25:47 Seun Ojedeji: Thank you Chris. Are you coming to the... Oh. Okay, I think we need to add code which was erupted before. Well, this is an add coded closure of the floor right now. So, we don't want anybody to come back to the floor please after ____. 1:26:08 Haitham El-Nakhal: Haitham El-Nakhal, Cairo Internet Exchange, I support this proposal. 1:26:12 Seun Ojedeji: Thank you. [applause] 1:26:30 Seun Ojedeji: Okay, I've consulted with my colleague and it's... Actually then asking for those who supports the proposal based on the edits that will be made, can I see your hands up? Thank you. [background conversation] [laughter] 1:27:02 Seun Ojedeji: Thank you, we've seen the hands. And those who oppose the proposal in its current form or even if it is edited, may I see your hands up? Thank you very much. We really appreciate your contribution to this proposal. [applause] 1:27:27 Seun Ojedeji: We have... I haven't declared yet. We have not declared yet. [laughter] 1:27:35 Seun Ojedeji: Okay. So thank you very much. The authors please, we hope that you implement the suggested edits, and send it to the RPD list for the last call process. Thank you very much.