Archives
Address Policy Working Group
5 November 2014
11 a.m.
Address Policy Working Group
5 November 2014
11 a.m.
GERT DÖRING: So, welcome back after the coffee break. Some will be still out there and grabbing more coffee, but I see most of you are already here. Welcome back.
In the first slot this morning I was still a bit too tired it seems because I forgot all the important announcements, like please remember this session is webcast, so, speak clearly into the microphones and so on. But you know that anyway, so, everybody who came up used the microphone, stated his name, and everybody who is on IFC knows there is Jabber and IFC so provide remote feedback. I mention it anyway because it's part of the drill, but you know the drill.
So, agenda for the second time slot is basically discussion of open policy proposals and nothing else. We'll see how it goes as far as schedule and timeline. I think we can ‑‑ we have plenty of time to discuss things. I might have to cut off discussions to give other proposals the chance to be discussed. But we are good as far as time goes.
The first thing on our agenda is 2014‑05. That's the policy for inter‑RIR transfer of Internet resources. Actually it's the respine of that proposal. We had that before, it didn't go anywhere, it was completely reworked because it was really done fresh, it got a new number. It's in review phase right now until early next week. The feedback so far on the mailing list was yeah, this makes sense but some wordings need to be more clear. And with that, I hand over to Sandra, who is fighting for this proposal for quite a while now, and volunteered to present it, argue for it, explain it.
SANDRA BROWN: Good morning. As Gert said, this is the policy for inter‑RIR transfers between the RIPE recently region and the other RIRs, and the full proposal is online that URL in case you want to look at it.
So, also, as Gert said, this is a replacement of 2012‑02, and the main differences from the previous version to this version are these four points on the slide. First of all, we have revectored the proposal to refer to resource holders instead of LIRs. Secondly there is a couple of points about legacy holders and resources so that we're more in line with what's happening in legacy policy that are being introduced. And lastly, we have had some issues and continue to have some issues with the arguments opposing the proposal regarding needs justification in the other regions and I'm going to come back to this point.
So, the feedback on the proposal. A couple of points I am going to speak to. Firstly, the policy: As long as the transfer is in effect the right policy police to the resources. So in other words songs the resources are in the right region the right policy police and once the resources move to the other region then the other region's policy should apply. So we are going to make that change explicitly and put it into the policy.
The second point and this is a little bit smaller font, but this is taken directly from the feedback that was given and it involves a feedback from both APNIC and ARIN regions. So, after consulting with the two RIRs, the ARIN policy requires "Needs based" explicitly stated, and it is felt that the policy as written, states only implicitly. So the difference between explicitly and implicitly. So, in the middle of this paragraph, "It is therefore not possible for the APNIC's secretariat to interpret and take a position because of the ARIN position. The APNIC secretariat indicates it's going to consult their community." So that has not happened yet and we don't know the final APNIC position. And then at the bottom, "The ARIN staff however notes that the lack of a specific explicit needs based requirement in the RIPE policy document will prevent the policy from being deemed compatible..." so this kind of puts us as at stand still in terms of transfers. So it kind of renders the policy useless.
So what we decided to do is to do a third version of the policy to address the concerns from the other two RIRs. So, we are going to come out with another rendition, I feel like I am building a career on this, and we need some input from you today when you come to the microphones. What we're hoping is that something like the four lines given here will get the agreement from the other two RIRs, so we'll simply change the statement that in the past version we had a statement that said, we'll have an operational process that will work with the other RIRs. Now we're going to go from that implicit statement to something explicit like "For transfers from RIR regions which require the RIPE region to have needs based policies, recipients must provide a plan to the RIPE NCC ‑‑ so it's within this region ‑‑ "For the use of at least 50% of the transferred resources within 5 years." So that makes it explicit. It's governed by the RIPE NCC and it's only for inter‑RIR transfers. So that means that the the transfers within the RIPE region continue not to have needs requirements. And that's my final slide and with that I'll take questions and comments and I'm really looking for feedback on whether this is something you can support, because really, we need to end this. You know, this is the third rendition and I'm really trying to get something through here and done. Elvis?
AUDIENCE SPEAKER: Elvis: I like, it I like it a lot. It's just I'm not sure and we have already had this a bit of line, I'm not sure whether ARIN will accept the five years 50% as being an acceptable ‑‑
SANDRA BROWN: John Curran, if you are in the room, would you mind coming to the microphone and speaking please?
JOHN CURRAN: Good morning, John Curran, president and CEO of ARIN. To be clear when the ARIN inter‑RIR policy was adopted in 2011, the staff assessment and what was discussed with the community is that any other RIR transfer policy that requires the recipient to have operational need for the addresses and requires demonstration of that need to their RIR would be deemed compatible. That's it. And that's what we told the ARIN community, staff would interpret the text because there is no minimum of any type in the ARIN policy. It just says you must have operational need and it must be demonstrated. To that extent, if RIPE adopts an inter‑RIR transfer policy that says that the recipient must show the operational need for at least 10% of the address space in the next 50 years, that will be deemed compatible and we will begin doing inter‑RIR transfers. And we have told the ARIN community that's how we interpret the policy. Now, obviously a completely specious needs assessment which cause the Karen community to go back and change the inter‑RIR policy. I can't predict the ARIN community. But any demonstration of need that's documented to the RIR will be compatible for our policy and will all have inter‑RIR transfers. Does that answer it?
SANDRA BROWN: Yes. Thank you John.
GERT DÖRING: Thank you very much. That was very clear guidance. Eric?
AUDIENCE SPEAKER: Erik Bais. A question on the specific timing. Can you go back one side? Is there a specific reason why you stated this specific at least 50% for the transferred resources within five years and instead of not following the timing used in the other RIRs, because, you know, those things change?
GERT DÖRING: It is pretty much arbitrary, it came out of the discussion on the mailing list. I think Sander suggested this specific wording. As we just heard, anything that's half‑way reasonable will good enough for the purpose. So, no, it's arbitrary. It's arbitrary but it's something that is fairly easy to document, so...
AUDIENCE SPEAKER: Eric: On the other thing for Sander. I really like the fact that you have taken the change of getting that operational thing out of the policy from the current version. Where you stated that the RIPE NCC has to work and make it, and make an operational procedure. I'm really glad that's out of the next version. I'm looking for to it.
SANDRA BROWN: Thank you Eric.
GERT DÖRING: Okay. Timeline wise. What we have now on the list, the feedback is good enough to ‑‑ well, declare this enough support to sort of like go into the next round. We have textual changes that should go in there. Since the review period ends next Tuesday, please. If there is something in the text that cannot live with, please let us know until next Tuesday. What I want to avoid here is that Sander sits down, writes a version 3 of the proposal, we put that into review phase and then you discover that there is something that you absolutely cannot have in there. Now is the time to make something that you can accept in version 3. So, if there is something that really needs to go or is really missing, please let us know on the mailing list until Tuesday, so we can integrate it or Sander it integrate it. And please don't wake up in the middle of version 3 review phase to find that cannot live with it. Because that's making my life more miserable than it has to be. And Sandra's of course, because she is the one who has to do all the new revisions.
So, if there is no more feedback on this, anything but what I have heard is good and positive then thank you Sandra.
(Applause)
We jump to the next block, this is actually five in one go. I have decided that we're not going through each of them individually, and have a round of discussion individually, because that means that I have about five minutes for each of them which is not useful. So, since they are all the same thing, basically, just applying to different policy text, I have agreed with Andrea to present them all in one go and then discuss them all in one go, because that's more reasonable use of our time, our your time especially. So, Andrea Cima from the NCC again who will also introduce the whole matter of why this came to be and why the NCC is actually making policy proposals here which is very unusual and we usually take great care to have the NCC execute policy but not make it. In this particular case, it's just clarification and mechanics that the Working Group tasked on the NCC, so it should be pointed out ‑‑ I should really stress this again, the NCC is not making policy. It's helping execute textual changes that came from the Working Group. With that, to Andrea.
ANDREA CIMA: Thank you, Gert. And yeah, I agree it's an important point that you have just made, the NCC is not making policy but here to support your discussions about these points.
Good morning everyone, I'm part of the RIPE NCC registration services team and I will present you the policy proposals with regard to language clarification in current RIPE documents.
Now, I want to give you a little bit of history where does this come from? Now we have to go back two RIPE meetings ago, RIPE 67, Athens, Jan Zors brought up an interesting story about him experiencing the ambiguity of some of the terminology in the Address Policy Working Group sessions in another RIR, and it was about the ambiguity of the meaning of "Should" and how this often is being interpreted as a "must" in policies.
The result was a discussion in the Address Policy Working Group at RIPE 67, whether this was an issue as well when it came to RIPE policy documents. And a discussion whether RFC 2119 should be used to define the language in RIPE policy documents.
Now, the RIPE NCC, at the end of the discussion, RIPE NCC staff was tasked to find all the ambiguous shoulds in the current policy document where the RIPE NCC interprets those as a must.
Now, that brings us to RIPE 68, Warsaw, the last RIPE meeting. Jan and Marco reported back to you during this session about the ambiguous shoulds in the RIPE policy document, and this created some discussion within the Working Group session, whether this was a non‑issue or this was something that needed fixing. Now, the outcome was that this needed further discussion and to eventually fix ambiguities where you as a community thought this would be necessary.
There was also support to have this gone through a policy development process formalised rather than what could be considered a cost metric surgery and it was also to discuss each policy separately.
What's the definition for should and must stand for in RFC 2119.
Now, should means that there may exist valid reasons why a particular item, circumstance, is ignored. But at the same time that the implications must be fully understood and carefully weighted before taking such a decision. One must ‑‑ that's an easier definition. It means that the definition is an absolute requirement. So there is the definition between the should and the must.
I will go through the different, five different poll proposals, where you see the red "must" in the text is where there used to be a "should" and these policy proposals have been published, they have already been discussed a bit on the mailing list, so that is good, there was some good feedback already and actually we believe that this may even be opportunity for you as a community to review the current policies, the current policy documents and to see if those, out of which some of them are quite old, if they still fit the needs of nowadays.
The first policy document that we are reviewing is the IPv4 address allocation and assignment policies for the RIPE NCC service region. In the 3.1 section, confidentiality, information passed to an Internet registry must be securely stored and must not be distributed wider than necessary.
The fact that if necessary, the information can be distributed on a wider level, on a further level within the Internet registry, it makes the use of the "Should "Which talks about an exception, redundant and for this reason, this was replaced with a why in the policy group also.
Still in the same policy document, we have section 5.4, suballocations. "LIRs wishing to convert their allocation to say PA status must contact the RIPE NCC" and the use of must here is simply because there is no other way to change the status of your allocation if not contacting the RIPE NCC.
Section 7.0, types of address space. "Clear contractual arrangements are mandatory for PA space. End users are requesting PA space must be given this or a similar warning." The fact that these contractual arrangements are mandatory make it logical to use the word must, because they are mandatory rather than should.
Section 7.0. For both LIR partitioned PA and PI, when the addresses are used a more specific net numb must be registered in the RIPE database. And we nought this up as must rather than a should because simply if you assign addresses this must be recorded in the RIPE database.
Now if we move tonne to 2014‑08, language clarification and contractual requirements for provider independent resource holders in the RIPE NCC service region. Is one title.
If we look at 2.0 section. Contractual responsibilities of end users and LIRs.
We say that, at the minimum, all contracts "must include..." because we are talking about at the minimum there is a constraint that at least those details and those points must be included in the contract. Therefore, the use of the word "should" would be redundant in this case.
If you look at policy proposal 2014‑09, in IPv6 address space policy for Internet exchange points, in 2.0 the definition section. We see that: "There must be a minimum of three ISPs connected and there must be a clear and open policy for others to join. Addresses needed for other purposes must be inquired through the appropriate means."
Now, this means that these resources issued for Internet Exchange point purposes in IPv6 can only be used for the peering LAN and that is currently how we are interpreting it in the RIPE NCC. Also, because also because this is in line with IPv4 resources for Internet Exchange point where the policy really clearly mandates that IP addresses issued for IXP purposes can only be used for the peering LAN and not for other purposes.
Then we have policy proposal 2014‑10. IPv6 addresses for Internet root servers in the RIPE region.
Also in this case, organisations must not use the address space to provide any other services not related to the root servers. And that is also how it is being interpreted nowadays.
And finally, 2014‑11, the RIPE document allocating /signing resources to the hike.
2.0, the RIPE NCC as a resource holder. The RIPE NCC as a resource holder must fulfil the basic requirements also expected of normal LIRs. This is because the RIPE NCC must give the good example and must not be different than any other organisations receiving resources.
So, these were the different policy proposal changes. I don't know if there are any questions or comments or...
GERT DÖRING: So, I have set aside 35 minutes to discuss these, so, please make good use of the time and give me your feedback. I see Jan already standing here, but well he brought this all up anyway, so, I also want feedback from somebody else. Like, for example, on the mailing list, we have had feedback from Nick Hilliard who said that the exchange point policy, that one should not be changed, should, must, whatever, that we should not implement the proposal to change it because IXPs have interpreted the word as a should and actually used the resources to number non exchange point things. So it actually would be helpful to have Nick stand up and argue the point a bit. But Jan first.
JAN ZORZ: As the cause of this mess, I would just like to thank you for taking the initiative and taking this further on your own. I would really like to thank you for this
GERT DÖRING: So... I'm definitely missing a rush to the microphones... so, maybe I will just steer the discussion a bit.
One of the counter arguments to this process I have heard to bring it up is that we take a policy document from 2008, like the exchange point policy. Change a single word to what we think was the original intention, and then publish it as a new document of 2014. So the counter‑argument against doing that was, if we actually touch the old documents, maybe we should go through the whole document and see whether it still applies, it still makes sense, instead of like having an old document with a single word changed published as new as that might cause confusion. I'm just relaying that as it was explained to me, and there is some argument to that. I still see nobody jump up and down. You are all hungry and want early lunch today, are you?
AUDIENCE SPEAKER: I think your comment you just gave is not really a good idea, because then you get so much more discussion on like a single policy to change it. So, I think it's better to do it one step at a time
GERT DÖRING: I'm happy to have a discussion. I have half an hour that I now need to fill with discussion. But okay, point taken. It was brought to me and I said I will relay it. Maybe we can just go quickly through the individual proposals then, and page by page, do sort of like a quick run through, and try to remember what the original intention was back in the day and provoke discussion a bit.
ANDREA CIMA: Okay. So this is the first policy proposal, 2014‑07 and the first change in, it in the IPv4 address allocation in the RIPE NCC service region. Confidential, as you can see here, the information passed to an Internet registry must be securely stored and the old text was should not be distributed wider than necessary within the Internet registry.
AUDIENCE SPEAKER: I have a general question. You mention the exchange points. Have we seen any cases where, as this sort of clarification means that we have interpreted it in different ways with just that the text is ambiguous but everybody has been sure all the time how it should be interpreted.
ANDREA CIMA: That's a good point. The point is that while in IPv4 Address Policy IPv4 Internet exchange points the policy requirement is very strict and says that IP addresses used for the peering LAN can be ‑‑ must not be used, cannot be used for any other purposes. The text in the IPv6 policy was a bit vaguer, a bit less defined, and we have received very rarely issues where an organisation wanted to use it for other purposes as well. But...
AUDIENCE SPEAKER: Has the NCC been looking into cases where sort of‑‑
ANDREA CIMA: This exercise was mostly about looking in general at all policy documents where there could be unambiguous text. So it doesn't mean that for every cases there have been problems or issues, because whether there are big issues we will bring them up during our feedback report, as you have seen previously. But there have been issues, or cases in this situation for example when organisations asked us if they could use the resources for other purposes and we told them that according to our interpretation, these resources would only have to be used for the peering LAN.
AUDIENCE SPEAKER: Okay. So it's not just cosmetic, it's actually sort of straightening up.
ANDREA CIMA: It could bring yes, it would make the interpretation of the policy stricter than what it would do in many of those cases, it could have an operational impact on some organisations.
GERT DÖRING: I need the need for an Impact Analysis that would tell us if we go forward with this, especially for the exchange point, how the NCC would handle existing cases. Because I think that's an important information. If you that an exchanges point has been using the addresses for other stuff, because they interpreted the "should" as a "shouldn't" and decided there's good reason to not follow this. How would you handle this? Because I think to decide whether we want this policy or not, depends on how it will affect people, existing deployments. But
SANDER STEFAN: It's important to be clear on the policy and I think in the case of the exchange points. This exercise uncovered some fundamental flaw in the way the policy is written. So, maybe this is not the right way to fix it and we should actually look into the policy more deeply and actually fix the policy itself. But if that's what we need to do, then I think this was a good exercise and it uncovered some work we should do now
AUDIENCE SPEAKER: I would just like a direct response to Daniel. Jan Zorz. When asked if there were cases, if you suspect you have a ticking bomb in your hand you just don't want the bomb to go off just to see what happens after. If you know how to stop it
GERT DÖRING: Yeah, but if you already have your services in there, that's ‑‑ it's some effort to change it. It might be easier just to block the change of the policy.
AUDIENCE SPEAKER: At that Shaw, consultant for Swiss and German Government. You asked for feedback and I would like to refer to the last slide, not to this one, but the one before. With the security information thing. And this is ‑‑ this really helps me because my customers always ask, oh what is about my information if I take part and provide information for address requests and this "must" really helps me and I interpret the silence in this room as a broad support of all this.
GERT DÖRING: That's a provocative statement and I like it because if someone disagrees they will jump up and tell me.
ERIK BAIS: Andrea, can you go back to the ISP slide. Question that I have: Are those organisations actually able to request an additional IPv6 block for their own usage?
ANDREA CIMA: Yes, for that you can request IPv6 PI or an IPv6 allocation.
AUDIENCE SPEAKER: Okay. So /TKRAOETed a /TKEUFRPBLG.
ANDREA CIMA: Correct.
AUDIENCE SPEAKER: By implementing this must, we cut out the rest of the organisation because they already have an assignment or an allocation for this?
ANDREA CIMA: That is correct.
AUDIENCE SPEAKER: Thanks.
AUDIENCE SPEAKER: Ollie /SKWREUBG sobs son. IP J. Since this is about language, I wonder if you had considered the work of your Stakeholder or the IETF where we actually have a document that talks about should, may and must, they always appear in upper case and they have very specific meanings. It might be a good idea to harmonise the language between the two. This is about policy and the other one is about protocols, but it's kind of ‑‑ it's kind of a similar thing I would have thought
GERT DÖRING: I think this is actually what started this, that there was ambiguity, and Jan pointed out there is 2119. As this is not an RFC, it's not directly applicable, so we decided to not use upper case, but just keep it as English, but a "must" in plain English is about as strong as an upper case RFC 2119 must I think.
AUDIENCE SPEAKER: As long as you have the definition, that you know what you mean by shall, must, and ‑‑ thank you
GERT DÖRING: We tried to make it as unambiguous as possible and that's not always easy.
ANDREA CIMA: Something to add to this is with the new policy proposals that have been made since then, mike was spending more time with the proposers to exactly make sure that the definition for the shoulds and the must that is they put in the policy proposals actually reflect its definition. So, this is to look back at the old policy documents that have been in place before that.
GERT DÖRING: Okay. Thank you anyway. Reconsidering, I don't think it's that useful to go through it slide by slide, because you have seen the slides, and I'm not sure it would evoke much more discussion to present each slide again. So, if you are really all silent about that, I take it as a sign to, well, move forward with it. Decisions are made on the mailing list anyway, so, if you support these individual changes and I understand it's a lot of different things to keep track of, please voice your support on the mailing list, and especially if you think something should not be done, please make it clear on the mailing list and try to explain why. For the exchange point policy, we have had a clear statement from Nick that he doesn't like the change for the reasons given, that it might affect existing deployments. For some of the changes, we had ‑‑ we have received support, for others we haven't received anything, so, I need more feedback to judge whether we go forward or abandon the project, or abandon one of the individual proposals.
If we decide to not go forward with one of them or with all of them, it's not a major disaster. In any case it's useful to look at the documents and decide what exactly do we think the policy should be, the policy text should be, and maybe if there is a should it should have been a should right from the start. Then don't change it. And, well with that, we are 20 minutes early, so, you might get off to lunch early. But we still have two more proposals to discuss, so maybe we actually need the time.
Thank you Andrea for preparing all this paperwork.
(Applause)
Which is quite a lot of process. And I now hand over to Erik Bais who brought us two new transfer policies, one for IPv6 blocks and one for AS numbers. He will have a presentation on both.
ERIK BAIS: Morning everybody. So, two new proposals for the ‑‑ basically which came out out of the Warsaw discussion, apart from feedback that we got from Andrea and I was the sucker that raised his hand and said yeah, I'll write both.
I want to thank Marco for assisting on writing the policy, and providing the feedback on how to do this.
So basically it's real simple. They are fixed policy basically. Currently there is some issue in the policies to actually, you know, if you are consolidating companies, merging LIRs, those kind of things, there is a policy gap and the issue is, cannot move your AS number the same as with the IPv6. I'll process the IPv6 one after this. You'll see that the presentation is quite similar as the issue is exactly the same.
So basically, this is how it is. It's currently not allowed to transfer AS numbers. And basically, this policy proposal basically fixes that the same way as we can with PI space and PA space for v4.
So, this is the question: What happens if you are actually doing mergers, merger and acquisition, which is you have an operational procedure within the RIPE NCC, if some question basically buys another company, that other company was an LIR as well, basically you're stuck with two LIRs in the same company, at some point in time you say well you know, can't we just merge those or consolidate those two LIRs and basically have one point, one company, one administrative point and one invoice from the RIPE NCC?
And this is where it gets interesting. So basically, the merger and acquisition procedure from RIPE, it actually goes into you know company A & Co B. In some cases, it's actually the company with two LIRs, and in that case, there is no resource change. So basically it's not ‑‑ there is no infrastructure which is moving, there is no services that are shifting, and in the current procedure from the RIPE NCC, it's actually seen as a transfer. And because it's seen as a transfer, you actually look at, well what can you transfer? And there is no transfer policy for AS numbers.
That's basically where the issue is. And specifically with AS numbers, it's after mergers or after acquisitions, and most of you are here are also involved in peering community, if you have AS numbers which are in use on an IXP and those ‑‑ you have old peering history relationships, that can actually be a real issue of having, you know, being forced to re‑number your AS number and your peering relationship. It's really ‑‑ it's a tedious task and in some cases, you really don't want that. So this is the goal of the company that actually wants to have, or this is the ultimate goal where they want to go. And this is basically what they end up with.
So, the operational procedure, it says, it clearly states, you know, it's infrastructure that needs to be involved to be applicable as a merger and acquisition. If that's not the case, you know, it's treated as a transfer. And currently it's not possible so you need to hand back your AS number.
So this is actually the comment on why this hurts with certain companies. And I'm sure that a lot of people here can actually relate to this.
So, the ultimate goal: We want to get the option to basically transfer AS numbers. The policy is pretty clear, it doesn't want to make things more complicated as they are. And basically, avoid you know, make it easier for companies to do this.
So, if you think this is a good idea or not, we have had some response on the policy already on the mailing list, and some actually stated we support the policy, give some more feedback if you think this is a good idea, do so on the mailing list. And if there are any questions on this, I'll be glad to answer those.
AUDIENCE SPEAKER: Tore: I don't have anything against allowing AS number transfers. But I have some misgivings about the way this is being done in a cosmetic sense. Because basically what we're doing is we took one screen full of text from the IPv4 policy, we copied number AS number policy, changed all occurrences from IPv4 to AS, and then you have the result and I know the next presentation for the next policy proposal does exactly the same for IPv6. And we have that paragraph now two places in the IPv4 policy as well, so we have a very redundant piece of text that just gets littered all over our policy documents. So I would propose to you instead of doing so for IPv4 and IPv6 and AS numbers, actually take it out of the IPv4 policy, you make a new document that's called resource transfer ‑‑ transfers of resources policy, and make it general so that it police equally to IPv4, IPv6 and AS numbers and you get the same result but it's much nicer to have in our policy documents. That's all
GERT DÖRING: Let me answer that. Right you are. The reason it's presented like this for the time being is that the Working Group group has the chains to say yeah AS transfers are cool but v6 transfers are not what we want. So, I discussed this with Eric why is it two policies and not one and why is it two presentations and not one? So you have the chance to decide on just one, both, none of them. On the other hand, Tore has a point so maybe ‑‑ so I could see, at the end of the discussion phase, if we actually find that the Working Group is perfectly fine with both, that we just withdraw one of them and we word the policy text for the other one or come up with a new one that does exactly what Tore proposed based on the positive feedback we have. We need a new one because of the changes.
ERIK BAIS: Because ‑‑ so you're right on the differences between the AS number and the IPv6 one and it's actually littering the current policy text, the documents. And there was a reason why I did it the same way also after the PI space. And the goal is to have, as soon as those two are actually done, we'll go through all the documents and basically clean up all the transfer related information and clean it up and make a separate transfer document. So, that is the end goal. But this needs to be fixed first.
I agree, you know, you can do it in one policy and basically one proposal and do it that way. But, this actually gives a more, a better option to say I like this one, I don't like that one without having to reiterate the whole process again with just one ‑‑ to have it in one document. Not everybody is as bold as you are Tore.
TORE ANDERSON: I would be happy with that if you actually take it upon yourself, assuming all of them pass, afterwards, aggregate them into one document.
ERIK BAIS: I will.
AUDIENCE SPEAKER: Than that's great. I was afraid that nobody would have the incentive to do so.
ERIK BAIS: I have already said it in Warsaw, when I was doing PI, this is what we're going to do and yes, it's redundant. These two need to be passed and afterwards, the goal is to have one policy document specifically about transfers, so that we can get all the other stuff out of the current policies.
AUDIENCE SPEAKER: Put inter‑RIR transfers in that document as well, even better results.
ERIK BAIS: Yes, if it passes by the time.
SANDER STEFFANN: I also think there is, if you look at the current policies, some parts of policy are in the same document, some are in separate documents, I think at some point in the near future, we should actually look at the whole set of documents that we have and actually see if we can restructure them maybe, to actually get rid of several texts spread out all over the place, so not just for transfers but for the whole set. But I suggest we do that after we get this done.
ERIK BAIS: Yeah.
AUDIENCE SPEAKER: Heather Schiller, Google fibre. Can you go back to the slide where it had the part of section 3, the piece of policy that was going to change, or that ‑‑ to update. Because there was a part ‑‑ I thought I saw it ‑‑ where it was saying that the piece of policy to change from section 3 to section 4 or to add a new section 4. The policy actually said that this is about ASN numbers that are not currently in use. So, if they are not currently in use, the IXs don't ‑‑ you wouldn't have to re‑number it, right? So, my point is the part of the policy that you are proposing to replace is about returning ASNs that are not currently being used, so if it's not currently being used what's the problem with returning it?
ERIK BAIS: Yeah... it's not the problem with the AS numbers not currently being used. It's about a problem having to return AS numbers that are being used, but because the policy is not there you have to, and ‑‑
AUDIENCE SPEAKER: There is a separate policy, I think it's like 585 or 595, and that says about doing like transfers and name change of organisations, and it covers all number resources so does that already address the need that you are trying to change?
ERIK BAIS: So basically, this ‑‑ by looking at the policy as it currently is, there is ‑‑ and I have to do this out of my head ‑‑ I don't know if there is a must or a should ‑‑ that you have to return unused AS numbers ‑‑
GERT DÖRING: I can answer that. Currently it's a must. And your text is actually changing that into a "should." So you are changing section 3 must to should. And adding section 4 with the actual transfer policy.
ERIK BAIS: Yeah.
AUDIENCE SPEAKER: I was trying to say it sounded like transfers were already covered under this other thing that broadly says number resources
GERT DÖRING: They are covered under merger and acquisition, if the NCC considers what you're doing to be a merger or an acquisition. And there are legitimate business cases that the NCC does not consider a merger, so in that case you are sort of like stuck.
AUDIENCE SPEAKER: It's just the examples given in the presentation sounded like the merger and acquisition example. So it sounded like the examples given as the problem statement, are covered by policy, existing policy. That's all.
ANDREA CIMA: Yes, there are some cases actually we have been contacted in the past instead by many organisations that actually cannot transfer an AS number. What we do not consider as a merger, that's not part of the merger process for legal reasons as well that if, for example, there is a holding organisation that owns multiple organisations that have a different legal organisation name, each of them has an LIR, the RIPE NCC has a contract with these individual organisations. For this reason, cannot, from a legal perspective, recognise the holding company, and when there is a request transfer resources from one of those LIRs to another, it is not seen as a merger or acquisition because there is no acquisition occurring, so in this case organisations will be able to transfer their IPv4 resources at the moment because there is a transfer policy for that but they will not be able to transfer their AS number and IPv6. And there was also many other cases where we have seen organisations contacting us just to transfer the resources, they for example hand over their IPv4 resources to another organisation without there being a merger or acquisition in place and they want to therefore all their resources but they cannot because at the moment they can only transfer the IPv4 address space. So some resources can be transferred, and some not and that is what was brought up during the last RIPE meeting, it can be a bit confusing for some organisations and does not always work out.
GERT DÖRING: Thank you. So, what I'm hearing from the room is that we might need a bit more of clarification on the cases, maybe some more examples to explain why this is a real problem even if we have a mergers and acquisition policy. I hear support, and nobody who says don't go there. Transfers are evil. I have heard that in the past and not today, so it is positive.
ERIK BAIS: Actually on the mailing list as well there are some people in the hallway here that stepped up and said well, I really like the fact that this will be possible. And also on the mailing list, so far, you know, people acted ‑‑ or spoke up and said yes, support the policy. So.
AUDIENCE SPEAKER: Does this mean that it will be possible in the future just to transfer the AS number to another company without actually transferring any resources?
GERT DÖRING: You are transferring a resource.
AUDIENCE SPEAKER: IPv4 and IPv6 resources, okay. Thank you.
AUDIENCE SPEAKER: Hi, Elvis. I haven't said anything about this until now. You have my support as well. So just stating that as well
GERT DÖRING: Thank you. Okay. Maybe we should for formal reasons do a quick run‑through of the v6 policy proposal which is the same thing with different numbers and different terms in...
ERIK BAIS: So, shall I introduce myself again? Basically, this is the same presentation, almost the same as the other one for reasons of the presentation archive I actually made an additional presentation about this. There is not much that will change in things that I have already said here.
There are actually differences between the transfer of AS numbers and transfer of v6 and I expect at least some reply or feedback on that specifically because, as we're now entering in the area of transferring v6, the case where one might say, you know, that might be interesting, is deaggregation for v6 blocks, we'll see how that goes, that is the only reason why I would say, you know, that might be why somebody might want to step up and say you know, I don't think this is a good idea. For every other reason, it's so easy to get v6, and the reason why we actually want to have this policy, the option to do this, is exactly the same as for the AS numbers. It's not like there is a shortage on it. It's just something we need to fix in the processors in order to make it easier for companies to consolidate.
So, we'll go ‑‑ silently through the whole presentation here.
So this is the part where I said well, that it may actually have an issue. I don't think that this is going to be very likely, or it's going to happen a lot. This is a really, really the corner case I think.
So, a lot of the same text both in the presentations and in the policy documents and I really hope that you'll allow me to fix this once we're in Amsterdam and I can actually say there is a new policy, transfer document, and we'll fix what we created ourselves here. Or at least I created. Questions?
GERT DÖRING: That's it pretty much. We have seen support on the mailing list already. If you have something, some good arguments why this is problematic, please let us know, please let us know as early in the process as possible so it can be amended if Ned needed. If you support it, let us know as well.
What I have seen so far in the mailing list is enough support to go forward to Impact Analysis and review phase, and then we will see.
ERIK BAIS: I believe the discussion phase is still until 28th November. I don't expect a lot of issues on the mailing list on either one of the proposals, in particular these two. So... you know, the sooner we can get the review and the analysis on it, that would be great.
SANDER STEFFANN: The discussion phase is now gone, the discussion phase is where you have to speak up so if you dislike the intent of the proposal or the direction this is going. There seems to be organisations that want this. If nobody else has any objections then that can be fairly quick and then the review will go into the details and the final wording. But so far it seems to be going well
GERT DÖRING: Well. I expected us to overrun by at least 15 minutes. Now we are finished half an hour early, which brings me to the awkward position of having to do some dances or so to entertain you or let you go to lunch. I take this as encouragement to not dance. ‑‑
Formally, we have the open policy hour and AOB always on the agenda, so if there is something that just came to your mind that you want to bring up, feel free to, you are welcome. You are always welcome of course, not only when I have time to bridge, but otherwise, thanks for being here, thanks for helping me, sort of like organise this. Elvis?
ELVIS VALEA: Since we do have a half an hour, why don't we talk a bit about the idea we just discussed, the new policy proposal regarding the limitation of /22 transfers. We were talking a couple of ‑‑ well, a couple of hours ago about the problem that ‑‑ so the problem that /22s could be requested from the RIPE NCC from the last /8 and then immediately transferred, which is not really fair, and we were talking about putting some limitations maybe into the policy so to ‑‑ yeah, not allow people to just sell LIRs for selling address space and making a profit. So, since we have half an hour, why don't we just talk about ‑‑
GERT DÖRING: Go ahead. Come up, take the microphone and lead the discussion. Somebody has to be the target for tomatoes. He is right, we have the time. It's a useful exercise while you are in the room anyway to throw around some ideas and then write this up afterwards.
SPEAKER: Basically, I had a chat with Wilfried about this, and as far as I can see personally, there are ‑‑ there would be possible problems. The first one would be that the/22s can be requested and transferred immediately using the transfer policy. The second one would be that any person, any company could become an LIR and request a /22 and if we do put a limitation in the policy saying you wouldn't be able to transfer them for, let's say two years, then that company could just sell their server that was used to justify the /22 through the mergers and acquisitions. So ‑‑ well basically that's how I see the two possible ways of getting this space and then sell it for a profit. So, the way I would see the policy proposal, it would say something like, the /22 that you receive from the RIPE NCC could not be transferred within the first two years, because it's a /22 received from the last /8, and because technically you should use this /22 in order to help your company migrate to IPv6, right. And if a company would do a merger and acquisition regarding this /22, if the LIR taking over does not have a /22, they could keep it, because it could be considered their last /22. If they do have already a last /22, then they should return it to the RIPE NCC.
GERT DÖRING: I'm not happy with the last part to be honest. I understand why this is proposed. I see a legitimate corner case getting in the way, so you have a company that has built a network with the /22, and wants to sell this off in five years from now.
ELVIS VALEA: If they want to sell it in five years ‑‑
GERT DÖRING: No, they don't want to sell the 22, they want to sell their business which has 1,000 used IP addresses, the buyer also has a 22 already, so one of them has to be returned, which is not the intent.
AUDIENCE SPEAKER: These two restrictions would only apply in the first two years. If you get the /22 and want to transfer it through transfers or mergers and acquisitions within two years, then you would either have to give it back to the RIPE NCC, or not be allowed to transfer it. You would have to give it back to the RIPE NCC if you do a merger and acquisition, and if it's not within the first two years, then it's fine
GERT DÖRING: With that extra, I think we have covered most of the corner cases I could imagine. So you just stick with the new LIR for two more years and then you transfer it. But that takes away the incentive to monetize it straight away ‑‑
SPEAKER: Exactly. Could you still monetize it in two years but you can't cover every single thing. It's just ‑‑ basically making sure that the ones that are thinking now that they could just request a /22 and sell it immediately, would not be allowed to do that
GERT DÖRING: If you have to pay for two full years of RIPE NCC fee and sort of like finance that upfront, and you might not get the money back in two years because the price goes down. This takes out incentive so this is ‑‑ I like it, speaking as myself. I think Wilfried is next.
WILFRED WOEBER: I think it's a very good opportunity to use these 15 minutes or so to discuss the ideas that we had shared during the break in public. I'm not so convinced that we should put the focus on returning address space, because I'm really fond of the ideas that had grown over the last couple of years to avoid different policy things with different pieces of the same resources. So like, we are trying to remove restrictions with IPv6 to have PI returned in the case where these addresses are used operationally. I'm not sure that we should sort of force anyone to return IPv4 addresses as long as they are used operationally.
My focus would rather be on trying and focusing to make it very difficult or close to impossible to transfer addresses if entity has received evenly additional addresses, whether this is by merger or acquisition, whether this is by the last /22 becoming an LIR and that sort of things. So this would be a limitation on the receiving end if this entity actually has addresses or hasn't and gets it by whatever means, then they should not be allowed for a certain amount of time, 24 months, whatever it is at the end, to transfer either the same IP address block or a different address block within their management environment and we have having that particular problem already in the whole time in the other policy where in my point of view there is no provision in preventing this stockpiling because you can get new addresses in and you have to keep them 24 months. But you have a lots of other addresses and you can sort of sell a different chunk. And I think all of those things are against the intention that we are having, and I think this is a good opportunity to look at the particular instance, this sort of creating an LIR, getting the resources, giving it away, getting money, closing down, this is one special aspect but I think we have a bigger field of corner cases. This would be one statement. And I don't know whether any one of with you wants to reply to that
GERT DÖRING: I think that's a worthwhile goal, but knowing the community, knowing the complications in our process, it might be worth the effort to actually separate those. Fix the new LIR 22 transfer away immediately issue, and at the same time look at the broader picture and put that into a separate action to avoid the the immediate thing being rattled into endless discussions about all the other transfer policies.
WILFRED WOEBER: I get your point.
SANDER STEFFANN: If I understand you correctly Wilfried, your suggestion would be to any LIR that receives resources, so any LIR that has incoming resources gets blocked for 24 months in regard to any out coming resources?
WILFRED WOEBER: Yeah, more or less that's the idea. Because even existing LIRs can get the /22 from the last thing and they might have a /13 or whatever, and if they actually apply for the last /22, I think they should be blocked from selling a /15 out of their legacy, that's my personal view recollect it's not a policy thing.
GERT DÖRING: Personally I agree with that, with my Chair hat on I think it will complicated to get that right.
WILFRED WOEBER: I agree.
GERT DÖRING: And that proposal is easier, because it's smaller.
WILFRED WOEBER: I agree, but I would still like to have this small group of people trying to come up with a focus proposal to also think about the other implications and try to find out whether we have similar problems in other policies. Before I'm going to the second one I might relinquish the microphone to someone else.
ERIK BAIS: So, the issue with the issuing of new LIRs and a /22, the 24 month waiting period for transfers, we can do that basically on newly issued or incoming resources, and basically expand that a bit. However, it's also possible to do merger and acquisitions of LIRs, and there is no policy for that. There is no 24 waiting ‑‑ 24 month waiting period for that, and after a merger and acquisition, one of the two LIRs is basically killed. So basically, how do we go about that? And maybe, also, the merger and acquisition is not something we can stop from happening, and also, limiting the amount of /22s in a single LIR is not going to be the solution, I think
GERT DÖRING: No, I think ‑‑
ERIK BAIS: What the exact solution is going to be quite hard, but...
GERT DÖRING: What I think I heard Elvis say is that you put something into whichever policy that says a merger of an LIR that has a /22, the LIR has to be older than two years. So you could use the address space right away but cannot close the LIR formally until it's two years old. So, you have to pay two times a yearly fee, which makes the whole business model of open the LIR, get the 22, sell it off, close the LIR, unfeasible, and that would be a success.
ELVIS VELEA: I was thinking to cover all the corner cases because there are several different corner cases. If an LIR requests a /22, and wants to transfer it, that will only be possible if two years have passed since the moment they have received the /22 right. That's the transfer part. That would cover all the transfers. If the LIR that has received a /22 is merged into or taken over by someone else, then again that /22 should have been received at least two years before, and if it happens within the two years, then it should either be returned to the RIPE NCC, it could be kept by the new LIR, the LIR receiving it, if that LIR does not have a /22 from the last /8, and in that case, it would be considered just like the LIR receiving it has requested his last /22, and actually that's it.
GERT DÖRING: If the receiving LIR already has a /22, the being bought one would have to keep their account open for two more years.
ERIK BAIS: Yeah, but that's still possible. You know, you are not required ‑‑ you can have multiple LIRs within the same company.
GERT DÖRING: Yeah, but that's not the case that we're actually trying to fix. If people really want to open five LIR accounts, there's hardly anything we can do to stop it. There's nothing reasonable we can do to stop it.
ELVIS VELEA: This would only try to fix the speculation, companies that come up from nowhere, or even individuals, become a member, request the /22, sell the /22 or go away or maybe come back again because it has been already a good business, right?
AUDIENCE SPEAKER: Sebastian, again. Are we sure that the two years are actually enough? I mean, has anyone gone through the numbers? I'm not sure how much people are nowadays willing to pay for a /22, but if you take the LIR fee for two years, is this enough to stop people from doing it
ELVIS VELEA: Well, you are investing 5,000 into something that might make you 6 to 10. So right now, based on some numbers, yeah, it wouldn't be worth keeping those /22s for two years in your LIR to transfer them, because you would not actually know what the price in two years would be
GERT DÖRING: The market might actually go down.
ELVIS VELEA: It may go up, so stockpiling is not a bad idea. But it may go down as well. So you have no idea what will happen in two years.
AUDIENCE SPEAKER: At least I think we should have an eye on that to see how it progresses over time, you know if that's ‑‑
GERT DÖRING: Andrea will keep us informed.
SANDER STEFFANN: Basically what is suggested now is that currently, they can open an LIR and do this with paying one quarter, and we're extending that to two years, so we're already making sure that the minimum cost they have is eight times as high. And possibly they can still make a profit out of it, but we're making it much, much less interesting.
AUDIENCE SPEAKER: Yeah, sure I just wanted to bring it up, because you know, who knows how it will be in five or ten years.
SANDER STEFFANN: Yeah, my crystal ball is broken at the moment.
AUDIENCE SPEAKER: Jason Schiller, Google. In the event that there is a legitimate merger and acquisition, and and an LIR is required that has a /22 from the last /8 and the inquiring company also has one, I am happy to pay the balance of the two‑year fees for the original LIR. It is problematic, however, for me to keep the original LIR open and to pay those bills from the original LIR when that company no longer exists. So, I have no problem with paying the fees and taking care that. Is it ‑‑ I would urge the community to consider in allowing that to be paid from the new LIR or at the time that the merger and acquisition happens
ELVIS VELEA: That would be difficult to put in policy.
SANDER STEFFANN: Basically, we were already discussing this in the break. And that would be a decision that has to be made by the RIPE NCC members at the AGM. So, it's not something we can do, if you merge with these resources you have to pay an X amount. That's going to be difficult. Maybe we can look into writing the policy in such a way that if the AGM decides that this is an option, then the policy can use it. We have so see ‑‑ but we're always careful about where the boundary is between policy and RIPE NCC membership decisions.
ERIK BAIS: So, in reply to you: If you actually do a merger and acquisition, you can actually decide to have the second LIR, the one that you buy, be added to your entity, your company entity. One entity can actually have multiple LIRs, so you can actually pay the bills and get the invoices from that entity. So your problem doesn't exist.
GERT DÖRING: Thanks. Good answer. Problem gone away.
AUDIENCE SPEAKER: I was wondering if this proposal is like an anti‑stockpiling proposal for IPv4 space, then what actually happens is people want to acquire more space will be doing it anyway and with any means, with any loopholes they might find in the policies. So this will result in running out faster of IPv4 resources and will result in earlier implementation of IPv6 by earlier adoption by ‑‑
ELVIS VELEA: The RIPE NCC will never run out of the /22s. It has more than a /8 right now to it has more than it had when the policy got implemented, when the last /8 ‑‑ well, I don't know if a large quantities are coming back to the RIPE NCC, at least we know that the NCC has received a /12 from the IANA, right? Plus what is coming back from 2007‑01 plus what is coming back from people actually doing the right thing and returning the space to the NCC so right now it has more than a /8 in reserves so it has more than when this policy of even implemented.
AUDIENCE SPEAKER: So what eventually is going to happen it's going to get harder to get address space for people who want to trade in address space, the price will go up.
SPEAKER: The price also go up.
AUDIENCE SPEAKER: Until the point where it's no longer make sense for people who are buying address space to pay the price and they will eventually go over to IPv6. The problem will solve itself
GERT DÖRING: The thing is that there is actually ‑‑ speaking to people I hear that there is actually large amounts of IPv4 address blocks out there to be sold off today, so the /22s are actually just a tiny fragment of the whole volume that is being traded today but the /22s have the wrong incentive. The policy is there to give people in ten years' time a tiny chunk of v4 to run their NAT 64 boxes on it and not to be acquired cheaply and sold off more expensively. The incentive today is not really right. It's not going to make a big dent in the market actually because there is a hidden liquidity in the market, like the /8s belonging to HP, so if they start selling off the /8s, the /22s are just nothing. So I don't think this will affect price much. But then, my crystal ball is also Clouded.
SANDER STEFFANN: I think ‑‑ and we have two different cases, the one we're talking about the loophole we're closing is the one that somebody starts up an LIR just for the purpose of selling off the addresses again. The other one, if somebody needs addresses for themselves, they can still set up multiple LIRs. So, if somebody needs the addresses they can come directly to the RIPE NCC still and set up multiple LIRs, but we're blocking ‑‑ trying to block the people who are just there to make money out of it.
WILFRED WOEBER: I think that's, what Sander said was more or less the famous last words. Because, I was about to say that during the coffee break we also had a chat and I took the position that I don't want to propose a policy with a background of trying to influence the market or trying to come up with a policy where we try to balance on a long term or mid‑term bases the cost of becoming an LIR and getting a /22, as compared to what you can ‑‑ for what amount of money you can sell it. What I would like to try to do is to come up with a policy proposal which is more or less agnostic to the price issue but at the same time try to sort of rate limit the burn rate of the last /22s, because our goal was to have as many of them available for as long as possible for those who need it to actually deploy the addresses in a real network. And that would be my goal, and this is just up for discussion, and as the proposal might fail in the end anyway.
GERT DÖRING: Thank you very much, thank you Elvis for making very good use of remaining time. That was a useful exercise. We have received direction how to go. I expect to see text from, well a group of you, whoever will put his name on the final proposal. Thank you for volunteering ‑‑ well, thank you all for contributing, and helping shape policy. And with that, we have actually used up our time and I wish you a good lunch. Thanks for being here. Have a good day.
LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE
