Address Policy
Wednesday, 10 May 2017
9.00 a.m.:
GERT DORING: So, good morning, dear Working Group. Looking into the room I can see that the party yesterday was really good. So I am happy that all of you still came out of bed, early morning, Wednesday, and are here to help us share policy. I think everybody in the room knows who we are, but still, politeness dictates an introduction, this is Sander and I am Gert Doring and we are your Working Group Chairs and we are happy to have you here.
First of all, the usual agenda bashing, telling you what is going to happen and asking for omissions, changes, whatever. First thing today on the agenda is actually Working Group Chair rotation because our policy says we have to change ‑‑ well, every Chair has to step down every two years and can step up again if the Working Group still wants him, so let's see. Then Marco will give us the usual update on regional policy making in the other regions, feedback from registration services, from Andrea, and something that is not typical on our agenda is item E, outdated references in policy documents, that is we might have a policy that points to an RFC where the IETF decide that had this RFC. No longer valid and has deprecated it, should we do something about it or not? More details to come. Then in the second time slot we will discuss the two currently open policy proposals and anything else that comes up. Word of warning: In the second time slot we are over there in the side room because we will be in parallel to the Connect Working Group and Connect reasonably claim that they have the larger attendance so we got the small room this time.
But I think that is fine.
If we ‑‑ if the time planning doesn't work out as intended, we will shuffle something up or down but we have plenty of time today so we are good here.
So, anything that needs to be changed on the agenda? No. Then, that is what we are going to do.
Minutes:
The minutes from the last RIPE meeting ‑‑ from the last Address Policy Working Group meeting at the RIPE meeting in Madrid have been sent to the list. A big thank you to the RIPE NCC for doing really good minutes as always. Well, thank you. And I haven't seen any comments on the list. Anything you want to see changed, corrected? No. So, the minutes are hereby declared final. And we go to the Working Group Chair selection process. As I said, our policy for Working Group chairing of the Address Policy Working Group says that we take turns in stepping down, so the Working Group has the chance to rotate out the Chair they don't want any longer. This meeting, it's my turn to step down and I said I will be willing to do another term, but it's yours to decide. So I am handing this over to Sander for the moment. I am stepping down.
SANDER STEFFANN: So, we need one Chair, we have one candidate so I think it's not hard but this is the last time you are getting away with that, because my term is ‑‑ ends next May so in one year and I have decided that at that point I won't be volunteering again. So, in the next year we need more candidates. So if there are people that are interested in this, please contact us in the coffee break or during this week, we can explain a bit more what is involved, how things work. Maybe train you up a bit if you need some training. But yeah, so up to now we usually ‑‑ the Chair that steps down automatically got reappointed but next May, please, we need some volunteers for this position.
Now, for this year, we have one candidate, his name is Gert Doring, he just introduced himself so, any objections to reappointing him as Chair? No. Then, hereby, we have consensus and welcome back, Gert.
(Applause)
GERT DORING: Well, thank you. This might look a bit silly and a bit like theatre but there is serious background here in having the chance to sort of give us the chance to reconsider whether we still want to do this, this is actually what Sander just said, and give you the chance to bring in new blood. If there is just one candidate and everybody agrees, it's indeed a bit silly.
So, current policy topics. Marco is, as you all know, the good soul at the RIPE NCC who does all the paperwork for us and helps us do everything properly, and he is of course also keeping track of policy development in all the other regions and brings back anything interesting that has happened over there.
MARCO SCHMIDT: Thank you, Gert, and good morning. And I would like to present you the regular update of current policy topics. First, I want to tell you a bit what is going on in the other regions, then I am going to give you a very brief summary what has happened in our region since the last RIPE meeting in Madrid and then I am going to close with some numbers from the policy development office.
But first off, what has happened somewhere else in the world and I can tell you already quite a lot. For the first time since many years or maybe the first time ever, all the other four communities in the other four regions are discussing more policy proposals than our community, so please fast enyour seatbelt, I am going to talk you through them now.
And I will start with AFRINIC. AFRINIC, they have currently two transfers proposals and a discussion, actually the first one, the IPv4 resource in the AFRINIC region has reached consensus also has been ratified by the board and is currently under implementation. This means once this will be implemented all the five regions in the world will have IPv4 transit policies within their region. Something that is still missing in AFRINIC is intra‑RIR transfer policy so to allow also transfers with other regions but they have one proposal and a discussion, it's mentioned here, it's the inbound transfer policy and that is quite interesting one because it only would allow IPv4 to be transferred to Africa, to the AFRINIC region, but nothing out. It's still under discussion and will be discussed in three weeks' time at AFRINIC meeting in Kenya.
The AFRINIC community is also discussing about the soft landing policy, maybe some of you have read the news a few weeks ago, AFRINIC reached a threshold of final /8 which triggered some landing policy which currently says that there is a maximum allocation size that LIR can receive, maximum/13 but there is no limitation how often an LIR can address more address space and there are two proposals that try to make that soft landing policy more strict. The first one mentioned BIS wants to reduce the maximum allocation size to a /18 but still puts though limit on how often an LIR can request address space, while the second one, the soft landing is SD allows maximum allocation size of /16 and would put 24 months' waiting period once an LIR has received up to a /16. So then they had to wait.
And there is another policy proposal under discussion right now that refers to the phase, that is called routing aggregation policy, because this proposal basically suggests as there is no limit how often an LIR can request an additional allocation, why not provide them an aggregated block if they send in multiple requests and qualify for multiple maximum allocation sizes.
There is more discussion AFRINIC, first one proposal is out there quite a while, Internet number resource review by AFRINIC, basically this proposal wants to put policy in place where AFRINIC looks more close to the address utilisation of their members and even deregister not used Internet resources.
Then the second one on this list, the anti‑shut down‑01, to you have been here on the plenary on Monday, you might know this, it's a proposal has created quite some discussion and attention, for the few of that you might not know about it, just let me tell you quickly: This proposal basically suggests if there are governments in Africa that restrict Internet access to part of their population, then as kind of punishment AFRINIC would not provide for 12 months Internet resources to this government and to related entities. And if this government would do this repeatedly, even AFRINIC would deregister resources that were provided to this government.
Quite a a controversial topic, quite some attention in Africa and also worldwide and, in three weeks in AFRINIC meeting I expect a very heated discussion there and there is a remote ‑‑ not exactly remote participation but you can watch remotely.
Another one, lame delegations in the AFRINIC Reverse‑DNS, the name also speaks for itself. This one tries to solve the problem of lame delegations and how to remove these records from the DNS entries. And last one, quite new, AFRINIC policy development process, so there is a proposal to develop the current BDP in AFRINIC, biggest changes there would be no could chairs any more, one Working Group policy chair together with a vice‑chair, and this chair gets quite some responsibilities and also quite some powers about deciding about rough consensus, and also they actually took over some ideas from our PDP because it also introduce periods like in our region a discussion phase, review phase and conclusion phase.
APNIC have three proposals under discussion, first one is to prohibit transfer of IPv4 addresses in the final /8 block, APNIC has a similar /8 policy like RIPE, basically once they reach a threshold of last /8 every LIR can get only one /22. And also similar like in our region, it has been observed that there are some organisations that become a member and try to transfer this /22 quite quickly afterwards. And this proposal basically, it suggests to introduce a 24 months' holding period which you cannot transfer addresses that you have received from the final /8.
This proposal returned IPv4 address management and final /8 exhaustion, has reached consensus at the last APNIC meeting, and to explain a little bit what is the intent of that one, APNIC is working with two IPv4 pools, one IPv4 pool is the actual last /8 so the, and they have a second IPv4 pool of all the other address space that they got back from IANA, from returned ‑‑ from closed LIRs. And every LIR gets first /22 from the first pool and if they need more they can get a second /22 from the second pool. And it was observed that returned address space that came from the last /8 was put to the returned address pool, which caused quite some confusion and this proposal basically suggest and it was agreed that returned address space from the final /8 also goes in the pool of the final /8 again.
And the last one in APNIC is called no need policy, and this name might sound familiar to some of you because we had a similar proposal about three years ago and it suggested there is no need ‑‑ when doing transfers within the APNIC region. Was discussed at the last meeting in APNIC quite some discussion about it, also there were some accusations that APNIC has a tool to measure support for a proposal that this might have been manipulated, but in the end there was no consensus and it was up for discussion again at the next APNIC meeting in autumn.
Moving on to our friends in North America, ARIN. As usual they have quite some proposals about transfers and how to ease them because ARIN has still quite a strict need evaluation. The first two months here have reached consensus, right now in last call. The alternative simplified criteria for justifying small IPv4 transfers, basically says if you can show a sufficient utilisation in the address space that you have, you can get up to a /16 via transfer without any additional need justification. The second one, to streamline merger and acquisition transfers, currently the ARIN policy manual requires the company that took over another company to prove to ARIN that they continue to use that address space. And that leads to quite some companies not wanting to update database because they didn't want to jump to all these evaluation and this proposal has removed this requirement that after merger you need to justify that you are going to use it address space that you just bought with that company.
The other two proposals just quickly, they are still under discussion: One suggests the slow start, that the requester doesn't need to provide 24 months plan for the transfer, rather they show how the address usage was taking up in the existing allocation over the last years, and the last one to remove the reciprocity requirement for Inter‑RIR transfers, something quite interesting because you might remember that AFRINIC has a proposal under discussion to just allow one way transfer to AFRINIC, and under the current policy this would not be compatible with the ARIN transfer policy. And that is why this proposal actually suggests to remove this requirement.
And to other proposals are still under discussion in ARIN, one is the removal of community networks, that is something very special in ARIN, there is a section about non‑for profit networks that are run by voluntary people and it was observed that never, ever somebody qualified to get address space under the section so it was suggested to simply remove it; however, at the last ARIN meeting, some people stood up and said, it's actually good that we have this section, we just should improve it so the discussion is going on.
And the last one on this list at the bottom, the annual Whois POC validation. This one is related to the global coordinated activities of law enforcement agencies, maybe you remember they reached out to the different communities all over the world, and that they would like to use the databases more for their investigations, and in ARIN there is already currently something, procedure in place that is called point of contact validation, a point of contact in the ARIN database is something similar like a personal object in our database and currently ARIN sends out an e‑mail every year annually that people have to validate the e‑mail is still working and if this e‑mail, if there is no validation taking place, the ARIN database marks this point of contact as not validated. And this proposal actually suggests to make that more strict, that this point of contacts will be marked as not valid and even after a longer period, even related resource objects, reverse delegation would be removed and also even the resources could be deregistered. And this caused also quite some discussion, people liked the concept of improving the data quality but many people not so happy with the punishment that would be included in that.
Moving on to the last of the four other regions, LACNIC, also there is quite some discussions. LACNIC also has reached their final phase of exhaustion, last /10, and they are actually three proposals that want to achieve almost the same, called minimum ‑‑ to modify the minimum allocation size, currently in this final phase of /22 and three proposals, one to reduce it to /24 and there are some little differences in some detail, that is why there are three different proposals. And also LACNIC is discussing now an Inter‑RIR transfer policy and similar like LACNIC they discuss a one‑way policy so only address space could go to LACNIC and nothing goes out.
Also quite some proposals related to IPv6 and we have two proposals with the identical name, to modify the size of the initial allocation, basically it suggests also in LACNIC to allow the consideration of criteria similar like in our region that, it's not just on customer numbers but also on hierarchical structuring and on security requirements and so on, and and rectifying the size of the initial allocation, this basically says if an LIR has received an IPv6 allocation they started to deploy and they need more address space, they realised they need more, then they can ask LACNIC for revaluation of their allocation size without the need of returning the initial allocation. Something quite similar or one proposal that we had just reached consensus in our region.
Last but not least, there are two proposals about resource recovery process, in LACNIC in the policy this is something if LACNIC considers some resources are not in use any more or not correctly utilised, they can verify that and can contact the resource holder and if there is no verification possible even deregister resources after three months. And the first proposal actually wants to be a bit more ‑‑ wants to extend the period, especially for critical Internet resources, so if there is some verification needed for Internet ranges that are considered as critical to LACNIC, to the LACNIC region, then the LACNIC board could extend that period within verification is necessary.
And the last one is to modify the resource recovery process. This one wants to make it more strict, that doing the three months where the resource holder needs to rememberify that they will utilize the address space if they don't respond after two months LACNIC could take away the reverse delegation to get the attention of the resource holder.
This was the global overview. I hope you are still with me, I know it was quite a lot, and I promise you the next two sessions will be really short.
So first on what has happened in our region since Madrid, since last RIPE meeting, we have right now two policy proposals under discussion, I will not say much about it because you will hear about them later today. And since Madrid, two proposals have been accepted: One is the RIPE resource transfer policy, this was quite long discussion about now consensus is reached, and right now RIPE NCC is busy with implementing and we expect that will be done until June. Basically, this combined all the sections of transfers for the different resources into one document. It also introduced 24 months' holding period for IPv4, and 16‑bit AS numbers after any change of holdership. And once implemented, RIPE NCC also will publish mergers and in our transfer statistics.
And the last one I just mentioned it, synchronising the initial and subsequent IPv6 allocation policies. This proposal has been published on the mailing list after the last RIPE meeting and it has reached already consensus so it went pretty fast. And it now allows the consideration of the same criteria for subsequent allocations than are out there for initial allocations.
One proposal has been withdrawn, it was already announced at the last RIPE meeting, the locking down of the final /8 policy which wanted to make that more strict and don't allow transfers of this address space.
I want to close with some numbers. I always observe how is the participation in policy discussions because it's more people participate, better this is to to find con suss suss amongst our community and adds to the credibility of the whole policy development, and last year was quite an active year, more than 1,000 posts, more than 170 people actively participated, meaning they sent something on the mailing list to a policy related topic and these people came from 30 countries. And this year is still quite young but already now more than 40 people from 17 countries are participating in policy discussions.
To putting this on a map literally, you see here a map of Europe and it's darker, the colour more people participate from that country. And you see quite nice distribution, I would say, some countries more like Germany or Russia and some regions I would still would like more like balance can area or Middle East but we are working on it to make these people more aware about the importance of policy making.
That is my last slide. Some useful links about the policy proposals, I mentioned a RIPE forum for all the people don't want to get more e‑mails to their e‑mail account, there is a web‑based interface where you can participate on mailing list discussions, and if you don't want to be on too many mailing lists you can simply follow me on my Twitter account and I put updates about policy developments in our region and globally.
That is the end. I am happy to take any questions.
GERT DORING: Thank you for bringing the update. You have quite a bit of stuff on your plate.
RANDY BUSH: Could you go back to slide 8, please. I, Phillip Smith and others were the initial authors of the /8 policies in, I think, this region in APNIC, etc., and the wording we used was, we didn't say /22; we said the current minimum allocation. Okay. So, that would be the general minimum allocation size, not just for the last /8, but for all allocations, and I raised the question, is it time to start discussing that here to drop the minimum allocation? I am not saying we go down this rabbit hole right now, but LACNIC is raising the question, and I think it's a good one.
MARCO SCHMIDT: Thanks.
GERT DORING: Let me answer that quickly, I think. I think the a reasonable question to ask. We should look at the numbers, get someone from RS to extrapolate on the current usage rate, how long is our stock going to last with minimum allocation size and see if we think this is reasonable or not. Are you listening?
MARCO SCHMIDT: I also can answer that because we are publishing this graph how it's going down and if I am not mistaken we currently estimate that we, if the trend continues with /22s we have about four years address space.
RANDY BUSH: Do you want to go down this rabbit hole?
GERT DORING: Let's have the two comments and come back to that.
GEOFF HUSTON: Numbers. February the 5th 2020.
MARCO SCHMIDT: More than four years.
RANDY BUSH: I don't think four years is very long. I don't think you are going to be able to start, for instance, an enterprise and not have a v4 address in front of it four years from now. Whether this is fortunate or not, you know, we all would love to live in a v6 world. I don't think we are going to be in a straight v6 world and the purpose of the last /8 was so that people could enter the game while we are still required v4 to do so, and I think two, three years from now we are going to be discussing /29 as the minimum allocation. Because we are just trying to get it out there so you can run NAT 64, right, let's be honest. So, I personally think it's time to start discussing getting that size down.
GERT DORING: Thanks for reminding us what the last/policy is about, to have something to start NAT 64 on. That was totally serious, I am not mocking you.
RANDY BUSH: I understand.
GERT DORING: It's good to have it in the open every now and then to be reminded.
RANDY BUSH: Many people think the reason for the last /8 policy so we discuss 38 more policies about modifying it.
GERT DORING: Obviously. So, I think it's reasonable to discuss this. Someone should volunteer to write a policy proposal to do that. I can't do that, you could, you could, you could. So let's see what happens.
RANDY BUSH: Somebody else want to work with me on it?
PETER KOCH: Peter Koch, DENIC. Totally different topic, could you proceed to the slide where you measure the participation.
MARCO SCHMIDT: Sure. You mean the map or the numbers?
PETER KOCH: The numbers so many people from so many countries and messages. I think that is a good snapshot and helps inform how broad the participation is to some extent, and with reservation about quality versus quantity, it's more request than a comment. If you do this next time could you like differentiate between substantive comments and plus ones, and factor out the plus ones so we see a bit more down to the substance. It's more work I know. It could help inform something.
MARCO SCHMIDT: I love more work so that is fine, yeah.
PETER KOCH: Thank you.
MARCO SCHMIDT: If there are no more comments, thank you very much.
GERT DORING: Thank you, again.
(Applause) the next one on the agenda is Andrea Cima, one of the regular items on our agenda is feedback from NCC RS, basically we do policy, they have to work with the result and sometimes it works well, sometimes it doesn't work so well, sometimes all the local RIRs are really unhappy with the policies so we need to know and fix things. This time I have been told there is nothing to be unhappy about so it's a review on what sort of feedback has there been in the past years and what came out of it.
ANDREA CIMA: Thank you. Good morning, part of the registration services time at the RIPE NCC. So, as Gert just mentioned, usually we get a spot in the Address Policy Working Group session so that we can from the registration services team report back to you. We report on the trends that we see now in our daily work but also report about complaints that we receive from our members about existing policies. We also report about a.m. big tease that we see in policy text. And we always ask to you do something, we ask you to discuss the issues, to provide us with guidance on how to interpret certain parts of the policies and that if needed, that you work on changing the policy to improve the situations available.
Earlier this year I was speaking with one of our members who had an issue with one of the policies and this person did not want immediately to propose a policy change, so we proposed to look into this to get some numbers, also because it was not the first time I was hearing about this issue, and proposing I can bring this back to the Working Group. See how the Working Group reacts and we can take it from there and the question that was made to me was, but is this really effective, will it have any impact if you channel our feedback to the Working Group? My first answer was, yes, of course, but then I realised we had never looked back at what you as a Working Group had actually accomplished over the last few years so this time I wanted to actually show you what you have achieved.
I divide the achievements in three areas: Address management, support to IPv6 deployment and data accuracy. And these are very important areas for the RIPE community, the RIPE NCC and I think especially very close to this Working Group.
So starting with address management, in RIPE 68 we brought some feedback to you, we informed you that we were seeing an increase in number of requests for transferring resources other than IPv4 addresses. Policy would only allow transfers of IPv4 addresses, no other resources. Now, you made two policy proposals and which reached consensus in the first quarter of 2015, quite quickly, and you can see that this change in policy has had a big effect on network operators. So‑so far we have transferred almost 300 blocks of IPv6 address space and more than ‑‑ we could see there was a need for changing the existing policy at the time it.
Another point was the referenced AS numbers, during the implementation of 2007 contractual relationships for end users we received a lot of AS numbers back and added those to the pool but kept them on the side because many of them were referenced. We still do receive AS numbers back which are not being used any more and many of those are also referenced. So, we did not really know what to do with those AS numbers at the RIPE NCC, shall we keep them on the side, that is a pity, these are valuable resources? Should we just issue them but they are referenced in other objects in the RIPE database and Internet routing registry. So we brought this up to you and discussed this issue and it was discussed in the Routing Working Group and from the two together the feedback we received was a mandate to actually go and reassign those AS numbers even though they were referenced. Now, since then we have issued more than 1,200 of those AS numbers and we haven't received any complaint so it means that mandate that you gave us had actually a big impact.
Another point is the multiple /22s per LIR. As Randy just mentioned, the last /8 policy is in place which means every LIR can receive one /22 of IPv4, not more, not less. The reason is so that everyone can have a little bit of IPv4 and that this is available also to new entrants in the coming years. There were a number of organisations, though, that saw a loophole so they started creating more and more and more LIRs, and the day after receiving the /22 they would transfer it away and close down the LIR account. In this way circumventing the policy that was set in place by the community and defeating the purpose of the policy.
I brought this to your attention and you acted on this immediately and there was policy proposal which introduced 24 months holding period, meaning you receive a /22 from the RIPE NCC, you are not allowed to retransfer it within 24 months. And we see that now the number of transfers of /22s for the last /8 has stabilised, you can see that the number was continuing to increase until July/August 2015, and since the policy was implemented, apart from one peak in December last year, we can see that the number of transfers of /22s has stabilised. So, this also has had a big impact on the pool itself and for how long it will last.
Coming to IPv6 deployment, it's something that many of you are involved in nowadays. One of the issues that we were seeing and one of the complaints that we were receiving from RIPE NCC members is that organisations that had received before becoming an LIR IPv6 PI block had to return this IPv6 PI block to the RIPE NCC once they became an LIR and actually wanted an IPv6 allocation. Unless they were able to prove that they would have a different routing policy. Many people would come to us and say I don't want to lie to you, we will have the same routing policy but I don't want to give up my IPv6 PI block which we are already somehow using, we have configured. About 50 LIRs were very honest with us, had to return to block, were not happy about it and upon the feedback you changed the existing policy making sure that organisations don't have to return their PI block if they receive an allocation. And since then we have not received a single return so people are happily keeping their IPv6 PI and for the deploying with their IPv6 allocation.
Another point that we brought up in RIPE 68 and 69 was the difference between IPv4 and IPv6 PI policy. This was quite confusing for many organisations because what you are allowed to do with the IPv6 PI is different than what you were allowed to do with IPv4 PI and, yeah, this was creating quite some unhappiness and confusion amongst organisations that are requesting address space. At the time we received the feedback to keep things as they are, it was fine like that, a few years later there has been a policy proposal to actually change this, and William will present this during the next part of the Address Policy Working Group session, so this is still open for discussion.
Then, one of the other things that we were seeing were the non‑let's say, standard IPv6 allocation requests. IPv6 policy was, we can say mostly written for ISPs, you can receive a block larger than /29 if you have a large user base. So, based on number of ‑‑ based on number of end users that you have, you can receive a larger block. That was the only other criteria. There was no way, though, for entities, organisations, which have different type of structure to get a larger allocation block. And I am talking about entities and organisations that based their network on different levels of hierarchy, for example, on a national base, or based on security levels. You created a policy proposal which was discussed and which was actually already ongoing when we brought up some numbers and additional feedback, and this reached consensus in October 2015. And since then we have been able to make larger allocations, several large allocations based on this policy change. We are not talking about a lot of allocations, we can count them on the fingers of two hands, but the total amount of address space issued is a lot.
Now, at a certain point the first allocation policy for IPv6 has been changed, you changed this, but this meant that the first and additional allocation policies for IPv6 were out of sync because the additional allocation policy was still only based on HT ratio and only based on user base. You changed the policy in order to align those two policies, meaning that organisations that receive first allocation of IPv6 based on the new criteria set can also receive an additional allocation based on the new criterias for hierarchy and security. This policy proposal has just been implemented, has just reached consensus in March so we are talking about very recently, and we are currently working with a few RIPE NCC members on their request for an additional block based on those criteria.
Now, finally, data accuracy. We reported to new RIPE 71 and 72 the fact that there were still more than 9.80 allocations that were issued a long time ago and had stated allocation PI or unspecified. These are things we could have cleaned up years ago but we ended up with them until recent days. What is the issue with those allocations? The issue was that they were inconsistent with policies because only the RIPE NCC is allowed to make PI assignments but if LIRs with allocations which hold a PA status they in fact can make PI assignments themselves, and with the allocated unspecified, there were customers of those LIRs that had address space but they did not know what type of address space it was, was it independent, did it belong to the LIR, this was creating a lot of confusion. So, we brought this up to you. I remember Hans Petter telling us it's only for ‑‑ bring them all in a room and discuss it with them and sort it out and that is, somehow, what we did after we received the mandate from you to do so. And I want to thank you the LIRs involved because they have put a lot of work and effort into it. And for the five out of 9.80 allocations have been converted so far (35) more than 600 PI blocks have been converted to PA and more important, 580 assignments to end users with the status not set out of 59.80 so there is only 10 left have been changed to a(mark numbers (what kind of address space they have.
Finally, that is point that we raised (nine) during the last RIPE meeting, and that is about a good number of AS numbers, about more than 6,000 in the region which are potentially unused. We asked you what to do with those and we asked you if we could go after this and verify with the users if the resource is in use or not and you gave us the mandate to proceed with our plan. So we will start this after the RIPE meeting, after the RIPE meeting we will contact the sponsoring LIRs for those resources and ask them whether the resources are still in use or whether they will be taken out and put back in the pool, hereby increasing the pool size of available resources but also cleaning up the registry data, making sure that there are no resources registered to organisations that maybe do not exist any more.
And I think this is it. This is not all of the cases, not all the impact that you had, there are more things that you have done, but I wanted to outline what I thought were some of the key ones and I wanted to thank you for providing us with the support to be able to take the actions that we take.
GERT DORING: Thank you. Thank you for the detailed feedback. It's important to see what consequences things have that we do. And I see lots of people on the microphone.
AUDIENCE SPEAKER: The question is, what does it mean after normal system is not in routing system, after between for example, five, four, normal system, routing and not visible global routing table, so what is the criteria?
ANDREA CIMA: Exactly, and this is something that we discussed at the last Address Policy Working Group session, we will not go and reclaim resources from organisations that say that they are using this space, we are not going to reevaluate the need for the AS numbers, we will do nothing like that. If we receive the communication that the AS number is in use we will stop it there. That will be it.
AUDIENCE SPEAKER: Good morning, and thank you, Andrea for the update. Very quick question on the ‑‑ speaking on behalf of Henkel today, very quick question on the status of cleaning up the inconsistent entries as for allocated unspecified and allocated PI, we hold several ‑‑ several AU blocks from mainly two covering LIRs, one of them have contacted us and we have resolved the blocks, the other doesn't react to any contact from our side. What are we supposed to do now, open ticket or those blocks are in use and we don't want to risk losing them or losing connectivity?
ANDREA CIMA: Like you mention, I think the most important thing here is if the blocks are in use, we want to make sure that we don't cause any issues to anyone involved. And about the specific case on how to proceed further I will be happy to discuss this with you afterwards, I do not know the details of the case but I will be happy to sit together and see what we can do.
AUDIENCE SPEAKER: I will get back to you, thank you.
RANDY BUSH: IIJ again. Am I correct in an assumption that the reason we are trying to recover unused AS numbers is we are really trying to it recover unused two byte AS numbers in particular, because we believe they are still really needed because there is a significant population that can't handle 4 byte AS numbers? Is that assumption correct?
GERT DORING: I would say sort of no.
ANDREA CIMA: I agree with that.
RANDY BUSH: You agree with the no?
ANDREA CIMA: I agree with him, yes.
GERT DORING: As far as I understood the original proposal, it's really housekeeping. We have resources, they have a stewardship to know where things are and if they don't see them they might have gotten lost.
RANDY BUSH: Fine, it was a reasonable answer, I am not complaining. I was just going to ask, if the answer had been yes, I would have asked: Are we still getting a significant number of people applying for an AS number saying I can't use a 4 byte? Is that ‑‑ is the 4 byte allocation still a real problem in the operational networks?
ANDREA CIMA: No, not really. What we see is I think we are almost 50/50 when it comes to two and 4 byte ASN issuing, so I think ‑‑ Ingrid can double‑check the statistics ‑‑
RANDY BUSH: 50% is significant, if 50% of the people are saying they can't use a 4 byte, we still have a technical problem.
ANDREA CIMA: Well, it's not that we receive a request because a specific need because they cannot use the 4 byte, it's we do not question the fact of why they would like a 2 byte or 4 byte. If an organisation asks for a 2 byte they get that, if they prefer 4 byte, 4 byte.
RANDY BUSH: Thank you.
GERT DORING: So, thank you.
ANDREA CIMA: Thank you very much.
(Applause)
GERT DORING: So, Marco is back now, so you don't get bored. In the AS number clean‑up discussion, somebody mentioned that the AS number policy reference is BGP, RFC and IETF that had been updated by the IETF in the meantime and questioned whether our policy had gone stale, referencing to outdated RFC. The RFC in question isn't actually outdated it just had been updated but the question ‑‑ what to do if one of our policy documents references something that is not valid any longer is a good one, so, we asked Marco to have a look, and here is the findings. Thank you.
MARCO SCHMIDT: Yes, thank you, it's me again. And I promise this presentation will be shorter than the first one. And as Gert already mentioned I want to give you an update about outdated references in RIPE policy documents. And just to explain a little bit, well, RIPE policies, they have quite some references linking to further information, and with this link making this external reference part of the policy. And there are three types of references: One is a link to another RIPE policy; another one is link to content on ripe.net, for example, procedure or guideline; and other is to external references and that is where the main focus of this presentation will be.
The first one, the RIPE policies, that is quite clear, in the case if something of this content get outdated for RIPE policies, we have the PDP so if there is any mismatch between policies, we have the policy development process, we can fix that. I will not focus further on that.
But what about the other two types of references? What happens if there the content is outdated? How can we fix that? And to give you a little bit of overview of the issue, if it is an issue of the situation, I found in seven policies and many also the big ones, the IPv4, IPv6 and the number policy I found references to ripe.net, that is mainly on the IPv4 policy, and to external references. I checked the references to RIPE to the net and they all were looking good so I had a closer look to the external references. And there, interestingly, I found quite some outdated references, three policies, the IPv4, the IPv6 and the S number policy have reach one reference to an RFC that is now marked as obsolete. Also the IPv6 policy and the AS number policy they have a special section where they list all references and in both policies in this special section they are still an RFC mentioned that does not mention the policy text itself any more so I have marked it it as orphaned referenced and also quite some references to RFCs where it's still valid but it has been updated but for now I think also less of a problem.
And to show you, these are the RFCs that are now marked as obsolete but RIPE policies are still referring to them. The the IPv6 stateless Atlas address auto configuration, special use IPv4 addresses and border gateway protocol 4 and the two orphaned is Internet standard process and initial IPv6 sub T LA ID assignments. So my question to you now is, actually, should we fix these obsolete and/or fanned references, and how to fix them (orphaned /STP‑FPLT (. It could be ‑‑ it could be maybe something more lightweight that specific situation is presented to you and there is a common period that you give feedback and if everyone agrees to change it then, there is an idea or might be an idea to do a bigger project, to look at all the external references, see if they are still needed, if we put the content in the policies and if not needed remove it completely. Even you might say, okay, it's not really an issue, let's just ignore it because so far there was nobody ever complaining to the RIPE NCC that except of this observation but before it has not caused any operational issues yet. There might be another solution that you come up with. And the second question is, should we monitor for you future changes to such references and then update you regularly, maybe during a RIPE meeting or doing on the mailing list? And with that said, I am looking forward for opinions
AUDIENCE SPEAKER: Erik Bais. I think the options are ‑‑ my preference would be this ‑‑ lightweight approach, so, track and trace if references would be outdated and as a process, as PDP officer, provide suggested updates and have a short comment period ‑‑ just update it, I don't think it's required to do a formal PDP on changes in RFCs if it's basically differences in RFC numbers that are being updated, that would be my guess.
MARCO SCHMIDT: Thank you.
AUDIENCE SPEAKER: ‑‑ German government. Normally I would say we should keep it as low formal as possible, but there is only one case if an RFC changes in the way that it has an impact on the reason why it was referenced so that the meaning of the RFC changed, this is the only case when there has to be a more in‑depth discussion how to go on with it. I think. So, therefore, it has to be a process, but normally simply the number changes but sometimes perhaps not.
MARCO SCHMIDT: Yes. Thanks.
RANDY BUSH: Randy Bush, RIPE ‑‑ bad idea fairy. I don't think you want to ask anybody to judge if there are significant semantic differences between two versions of an RFC. Don't go there. I think the IETF has been pretty formal about when an RFC is updated or obsoleted in the header, it points to the new RFC. So, the option of ignoring does not mean we are pretending it's not a change or problem; it could mean rely on the forward pointer in the referenced RFC. Was I clear? Because ‑‑ okay.
MARCO SCHMIDT: Yes, if I can ‑‑
GERT DORING: It was clear, these this voice was just don't change anything and rely on the document pointing to the new version anyway. Bush and the IETF is very formal about making sure those forward pointers are correct. And ‑‑
GERT DORING: Which still leaves us with the unreferenced references so we might have to do some lightweight clean‑up.
MARCO SCHMIDT: I want to add, currently the reference on the web policies doesn't link directly to the page, rather to IPF server of the RIPE and it's not showing if it's obsolete or not.
RANDY BUSH: The FTP server ‑‑
MARCO SCHMIDT: ‑‑
RANDY BUSH: Has a copy of the RFC and right in the header of the RFC ‑‑
AUDIENCE SPEAKER: It's a copy before it was updated, just ‑‑
GERT DORING: Which is not good, we definitely heed to look into this. Either change the reference ‑‑
AUDIENCE SPEAKER: RIPE FTP server ‑‑
RANDY BUSH: Well that is another problem.
GERT DORING: We need to look into these ‑‑
RANDY BUSH: I have a proposal, learn how to use R sync.
PETER KOCH: DENIC. I have one question and one or two opinions, going back to your orphaned references, you mentioned that RFC 2026 which is the IETF standards process is orphaned, what do you meanby that?
MARCH SCHMIDT: Basically, it says ‑‑ well these two policies, the IPv6 and they have a special section where all the references are specifically listed with the links but in the actual content it of the policy, there is no ‑‑ this RFC is not mentioned any more.
PETER KOCH: It's orphaned in the document itself or a useless reference?
MARCO SCHMIDT: Yes, I should maybe have said useful reference but I wanted to use something more proper.
PETER KOCH: Diplomacy is on your side, it's okay. That is okay then. And I have complained about this before when we updated documents and the updates, the change red line version, whatever, did not mention new RFCs like 3330 is a prime example, so the least we should do; whenever we update a policy document for some other reason, to very, very carefully look at the references and evaluate them. This is not a clerical editing task like replacing an RFC number by another, there might be changes in content so it's a bit more than that. And I am sorry to disagree with Randy here, there is no forward pointer in RFCs because they are immutable, there are pointers in the RFC editors representation of this and by means of linking but that presents the same problem, but just saying that we are now referencing to the RFC or any subsequent version, depending on how important the content is, it depends. Again, it also depends on whether it's informative reference as the idea would say so the general response is it depends and since you have started doing it the work and it's part of a larger issue because we found out in another venue for our own documents we are sometimes unclear about their status and their relevance for the day, this is a good way forward. But it's a case by case decision and I don't think there is a general process we can apply here. Thank you.
MARCO SCHMIDT: Thanks.
Elvis: I think we should just present comment change. Any changes in RFCs mainly that changes in the content have been made that were not in the main idea of that policy, and I think that whenever an RFC is updated, then this should be presented to the RIPE meeting or mailing list, should be discussed maybe not formal PDO one month process but maybe a week or couple of weeks, and we are not really in a rush to change them so maybe this can just be presented at the RIPE meeting and have a show of hands, hey, do we accept this change to be updated as an editorial change or do we actually need to have a formal discussion and have this updated through PDO, because right now, the RFC means something completely different than what the previous one meant.
GERT DORING: I don't think we should do by show of hands at the it RIPE meeting, because the underlying philosophy of the Working Group is it's open to everybody, everywhere, you don't have to go to RIPE meetings to influence policy making and document clean‑up so having a light wide process is good because the formal process is too heavy but I would definitely go for list, like send a short note to the list with, this is a the proposed edit, four weeks of common time and then the Chairs say, just go forward with it or there has been substantial opposition because the new RFC is different, and then we can still take the formal away. So that would be my suggestion from what I heard, bring it forward on a case‑by‑case basis to the list, have a four‑week comment period, and then the Chairs evaluate on a case‑by‑case basis if it's just a simple edit like removing the orphaned reference that is pretty straightforward, or the new RFC has significant changes and we might reconsider whether we want to link to the new, the old one or not at all, and that is a heavy process, I think.
AUDIENCE SPEAKER: That is good as well. I just thought if we ask Marco to bring this at the RIPE meeting, anyone can participate at the RIPE meeting, that they don't have to be present in the room, they could be on chat.
GERT DORING: That is the theory but the practice is the list is what counts.
AUDIENCE SPEAKER: Okay.
HANS PETTER HOLEN: RIPE chair. I am all for lightweight, but my question would be what do you want to achieve by lightweight? If we are going to do changes to the policies it should be properly documented and tracked, the PDP takes 19 weeks I think if you to it sort of the rough way, the first four weeks is initial discussion, so the sorting out of whether there are substantial changes in the RFCs that affect the policy or vice versa would fit in that box, then you have the final draft and then there is a comment and review of no more than four weeks, well, then at least everybody knows about it and then there is a last call of exactly four weeks. So, why would we do a sort of process in order to save Marco some work, sure, I understand that, but if this is urgent, yes, I see the point of that but then that may be cite eek of the PDP that we need a quicker PDP in urgent cases as well. So I don't really see the big benefit of trying to invent a new process to do a lightweight update on this. That is just my five cents
GERT DORING: The PDP is very heavyweight process, and if we are ‑‑ it's heavyweight for a reason... the thing with the PDP is, it requires active support in every stage except for last call and if we throw in ten formal proposals into the machinery, nine of them document aerial and one of them serious, I have a prediction what will happen; we have have no feedback on any of these and then the whole machinery grinds to a halt. With the experience of the last ten years having too many formal things that really require feedback from the group, formal feedback, formal summaries from the Chairs and so on, is something that should be reserved for true policy changes and dropping an outdated reference and editorial changes. We have done document clean‑up with must and should with more lightweight process before. When the Working Group agreed that this is not a policy change but a textual clean‑up, that is the point. We can do textual clean‑ups if the policy itself isn't changing without invoking the PDP. There is precedent that we can so I claim we can. But we can take this off‑line.
PETER KOCH: DENIC. Surprisingly I am a sceptic of the lightweight religion here, like Hans Petter and for a reason that he actually gave, if it's urgent then it's probably also important and it needs more attention than saying this is a clerical change. What I wanted to ask and what brought me to the mic another time is, Gert, actually, that is your name, right, you said we report this to the relevant list or competent list and make that change. Would we issue a new document number?
GERT DORING: Yes.
PETER KOCH: Okay.
GERT DORING: Because the text changes and if the text changes we have to have a new document number, update the references to it.
PETER KOCH: That also means we get a new time stamp on it and I agree there should be a new document number to avoid any confusion but it depends, it's a case by case decision, content changes over time and not only the references might be outdated... but some of the content as well. So defining the quote lightweight process might be more heavyweight than defining the PDP and if it's so heavy we try to avoid it every time this is self‑fulfilling prove see. Marco has come up with seven documents after all these years and trying to do stuff with one of them, less controversial ones, shouldn't be too heavy. Give it a try. Trust your own procedures, our own procedures. Or get rid of them.
GERT DORING: I am hearing you.
Erik: One of the biggest issues that I see between the formal PDP and the lightweight version regardless if we use the same process, is that we also need to have more editors or authors for the new versions, because somebody needs to drag this through the PDP process, if we select that this is going to be the formal PDP process it is not going to be Marco. I think this is the biggest issue.
AUDIENCE SPEAKER: I agree that probably we don't need the formal PDP process, but we run in another registry in LACNIC in similar situation, with it another review of the policy book, and what we did to fix that was a small design team of people making a review of all the policies, looking for broken references or whatever, and then bringing a single proposal to modify all that to the PDP process. If we really need to go, I don't think so, but if we really need to go for the PDP process we could do that. If that is requires some volunteers, I am happy to step up.
GERT DORING: Thank you. So, what are you going to do? I think with a we should do is, you send an e‑mail to the list with your findings which documents which references what and if it's not too complicated to navigate IETF to actually point to the new RFC or why it has been obsoleted or so or just point to the proper web page where this information is present as we have heard. I think and then we as the group look at the findings in detail, and decide how to do it. So there is clearly no clear consensus in the room for a given way forward so ‑‑ we defer to the list as always.
HANS PETTER HOLEN: As long as you are able to convince the RIPE Chair that this is done in open and transparent way I am sure we can find a way to do it.
GERT DORING: I will do my best, there are smoke‑filled corridors somewhere here. That I think brings us to the end of this agenda item. Now we have 15 minutes before the break, I wonder if Max is already here, do you want to tackle this now or after the break? We tackle Elvis proposal because I think 15 minutes is a good use of our time, while everybody is still around and then we do the IPv6 PI discussion after the break in the other room. With lots of time. It takes a second because it was planned to be in the other session and that is why the presentation system ‑‑
ELVIS DANIEL VELEA: Good morning, so, I am here again, let ‑‑ it's actually better. There have been quite a few discussions at the various meetings, including the past couple of RIPE meetings, some ARIN and APNIC meetings and etc., etc., several presentations from various people saying we are going to show you this information about transfers but it's missing RIPE intra‑RIR transfers of legacy space because the RIPE NCC does not publish that. So, after a few discussions with all of these people, after a chat with Marco, I decided that it's a good idea to actually make a policy proposal change ‑‑ policy proposal. So, 2017, what does it change? It changes two documents: One of them is the RIPE resource transfer policy and here it adds a requirement for the transfer statistics that changes in the RIPE database to the organisation holding regular see resource should be published. So that means this requires the RIPE NCC to publish updates of legacy blocks and consider them a transfer.
Second thing it changes is the RIPE NCC services to legacy Internet resources and it adds transfer services to the services offered to the legacy resource holders. Why was this needed? It was needed because the RIPE NCC did not have a mandate to require any kind of documentation from the legacy resource holders to be presented in case the legacy resource holders did not have any contractual relationship with the RIPE NCC. So we have two situations here: The first one is, does the RIPE NCC have formal contract with the legacy resource holder, be it either an SS A or legacy resource contract or the legacy resource holder has a response soaring LIR relationship with an LIR and has the legacy covered by that contract. And so that is the first thing we have. And then we have the possibility that the legacy resource hold every does not have any contractual relationship with the RIPE NCC. In the first situation where there is some sort of a formal relation, the RIPE NCC will have its own maintainer added to the legacy resource and will see the changes and will follow up on these changes with legacy resource holder. On the second case, where there is no contractual relationship, the object is not maintained by the RIPE NCC only by the legacy resource holder and therefore the legacy resource holder can update that object to point to another organisation and the RIPE NCC would not even know about it ‑‑ well, the current status of the policy proposal is open for discussion, so I would like you to speak your mind on the mailing list if you have any comments, contra or against this policy proposal. The current phase started on 25th of may it please and it will end in a couple of weeks and the Working Group is Address Policy. We decide that this would be better in the Address Policy Working Group because it still refers to addressing and to resources and actually Gert and Sander had a chat with the NCC Services Working Group to see whether this should be proposed in that Working Group and the decision was now let's have it proposed here in the Address Policy.
So, as I said, this already started on the 25th of April. The pros for this policy proposal are the following: First, well, we already see on the RIPE website statistics on transfers of allocated PA, assigned PI and Inter‑RIR legacy transfers, or any kind of transfers, actually, Inter‑RIR transfers of any kind of resource. We do not see the intra‑RIR transfers, and for consistency and for the bigger picture it would be a very good addition. Now, there is another as well thing, an added feature maybe or security bug, whatever, right now if legacy resource is maintained by an object, bay maintainer, by a lock and someone gets their hands‑on that maintainer, they could update the object and even change the maintainer on that object, and it may be that the company holding that legacy resource may not even be ‑‑ may not even exist any more, regardless of whether the actual legacy resource holder exists or not, someone might get their hands‑on the maintainer and might be able to update the object, then talk to a buyer, transfer the block, there would be no formal involvement of the RIPE NCC in this process so they could just update the object, transfer it to another party and then whole mess will be created, because the buyer would pay the seller, right, the object would be updated in the RIPE database, it will show the name of the buyer, but the actual owner or holder of the legacy resource could go back to the RIPE NCC and ask, hey, why was this changed? I am the legacy holder, this was hijacked. And I think and maybe I will get a confirmation from the RIPE NCC if, this case is happen and if a block is hijacked, even if it's legacy the RIPE NCC will revert it it verifying that this was indeed an attempted hijack.
So, this causes problems to potential buyers and sellers of legacy resources. By having this process where the RIPE NCC will verify any update on the holder over legacy resource, it will add some security to both parties.
Also, I have seen that not a lot of people know the difference between the RIPE database and registry. The RIPE database is the database where we could update stuff, or the RIPE NCC could update stuff and it's public in the RIPE registry, the RIPE registry is not that visible and it's basically ‑‑ the registry of the numbers and the RIPE NCC publishes the delegated extended files where ‑‑ that is basically the registry itself. And researches on IPv4 cannot really see the whole picture. There is a tiny bit missing out of it and therefore they cannot make good predictions and cannot understand the whole picture and it's a good idea to see the whole picture in its entirety.
Also the quality of the RIPE database, reg, would be increased if this would go through. Now, we had a few comments on the list, Sasha says it does not have a mandate to approve changes, it doesn't have a mandate to impose a process to it the legacy resource holders and that they might be generating free intelligence for brokers and wasting monies of the members. We had a quick chat on the mailing list and he finally said that as long as the process is voluntary and the language is added to clarify this point he was going to withdraw his objection. Carlos also said that the main goal of the proposal is to add extra requirements for legacy resource holders, an extra workload for the RIPE NCC and legacy resource holders. He hasn't actually come up with another better idea, and I am hoping that once we actually improve the verbiage he might no longer be against it. Erik Bais was talking about Inter‑RIR and not intra‑RIR transfers and well, most of the discussion ‑‑ most of the e‑mails from Erik were talking about something that has nothing to to with this policy proposal. Leo asked why this was not proposed in NCC services and answered by the Chairs this was already discussed and it was accepted this would be in address policy. Randy Bush was linking to his presentation, thank you, Randy. Nice presentation. And James Kennedy offered general support. We might have had another support from Stephen, we don't know, he just thanked me or Marco for the e‑mail. And then David farmer actually said had a we should be even rougher than what I intend and actually make this process mandatory, not optional. This would improve the registry, this would improve the information presented and having this as voluntary will expose sophisticated buyers to a risk from fraudulent actors.
So, this would add protection to the legacy resource holders. Those who are comments up until now, let's have a chat about it, please.
GERT DORING: I expected the presentation to be something like five minutes so we could have ten minutes of discussions, now it's two minutes before coffee. And I see the need for proper discussion of this, not two minutes and then overrun into the coffee break when we have a whole second slot to spend on discussion. So, maybe five minutes of warm up discussion and then we definitely take our time ‑‑ my watch says we have a minute, one minute of warm‑up discussion, two‑minutes running into the coffee break and we continue after the coffee break.
Erik Bais: Nice summary, yes indeed I was discussing on the mailing list about the difference between the Inter‑RIR and intra‑RIR, my policy for that. On the ‑‑ in your presentation you stated specifically that it's difficult for buyers and sellers to see if a block was hijacked from or if it was changed directly by somebody having access to the maintainer. You are aware that the database actually keeps history and you can actually look up previous versions and you can do that, that is public information.
ELVIS DANIEL VELEA: I am aware of that. You don't know whether it has been updated, whether the company that is shown currently the RIPE database is the actual holder or whether this block was hijacked and it's in the name of someone that doesn't actually have the authority over it.
Erik Bais: For proper due diligence and you see changes in the original ‑‑ if they cannot produce the proper documentation it's a single e‑mail to the RIPE NCC: Is this still veiled and currently also in the registry.
ELVIS DANIEL VELEA: What do you want the RIPE NCC to go, to ask the legacy holder are you still holding this, is it still yours? .
Erik Bais: If you ask the RIPE NCC is the current holder or if what you see in the database is that also reflected in the registry you also have that same verification.
ELVIS DANIEL VELEA: I don't know, well, maybe someone from the NCC could respond but I don't think the RIPE NCC can actually confirm whether that is the right legacy holder unless they start doing a lot of vetting, asking for a lot of documentation, etc., etc., and you are going to go to the RIPE NCC, not as the holder but as someone else, either the broker ‑‑
Erik Bais: As a potential buyer you can request that information ‑‑
ELVIS DANIEL VELEA: And the RIPE NCC might not be able to give ‑‑
Erik: You can ask them is the information in the registry current with ‑‑
ELVIS DANIEL VELEA: Let's discuss it a big later.
GERT DORING: Two quick comments from these gentlemen and we go on in the next room.
AUDIENCE SPEAKER: Maybe I will leave it until after the break.
GERT DORING: You know whether it's a quick comment or not.
GERT DORING: Please let's have it after the break. Thank you. Enjoy your coffee and if you are interested in this please be back after the coffee break in the other room. Thank you.
LIVE CAPTIONING BY AOIFE DOWNES RPR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE
