These are unedited transcripts and may contain errors.
Notice: Use of undefined constant steno - assumed 'steno' in /var/www/html/ripe-60/steno-transcripts.php on line 24
Address Policy session, 2 p.m., 6th May 2010.
SANDER STEFFANN: Sorry for the delay. Welcome to the third session of the Address Policy Working Group. Here is the agenda for today.
Basically today we are going to discuss all the open policy proposals and at the end, we have the open policy hour where some new ideas are being discussed.
So, that's this part. For the discussion, please speak into the microphone. The session is being webcast, so please state your name and affiliation, and we have remote participants, so they could send in some messages through Jabber.
Okay. The first proposal of today: 2006?05, it has been around for a long time. I'll try to explain it a bit why. This proposal was introduced in 2006, but then it was postponed because of all the PI contract proposals. So 2007?01 to be precise and after that it basically got stuck. It has no active proposer at this time and we were planning on with withdrawing it. But during ?? in the period between the last RIPE meeting and now there were already two people asking for something very much like this proposal. So, we are actually looking at people who think this is important and would like to pick this up. If nobody steps forward, we'll have to really withdraw it, but because the item has come up, we would like to give you one last chance for that.
Then we have another proposal, 2008?07. A bit of history here. It was introduced in October 2008, and it's basically about the historical resources. So, resources from organisations have from before the RIPE NCC. Currently, those resources are not taken into account when people ask for extra address space, or if they want, even want first first allocation. So this proposal proposes to change that, and to take that space into account. The first version just talked about the, additional addresses. The wording was a bit changed in June 2009, and in July ?? 2009 it was changed so that it will also apply to initial allocations.
So, with with with this policy proposal, some people felt it would be more fair because otherwise people who already had some pre?RIR address space would be able to request a big block of addresses potentially.
This proposal has also been stuck for a while, and we are not sure how to move forward with this. I would like ?? is there anybody who thinks this is important? So maybe, a show of hands? Should we continue with this? If we do, we will of course do it on the mailing list, but is there somebody who thinks this is still important for IPv4?
I see no hands at all. Sorry,
AUDIENCE SPEAKER: Wilifred. It's not a show of hands but a question: Basically I fully support the idea that whenever you want to get additional address space you have to disclose what you have done with the address space you already got before so that this is not to be discussed. I am just wondering if some entity happens to be a legacy class B and for whatever reason IP tends to for example, become an ISP, we will probably one into the probably of having to convert legacy address space to parks address formerly and if this is going to fly in the end with the routing filters is an open question to me. But that's operational. That's not policy, so... it's not clear to me whether this was considered already during the discussion.
SANDER STEFFANN: Okay. I'd have to look it up too, I don't remember all the details any more. But, from your replies, I get the feeling that people don't think this is really worthwhile any more. So, I will discuss it on the mailing list, raise it on the mailing list one more time and ?? it has been stuck for sometime, so if nobody speaks their opinion, we will have to speak with the proposer to, how to continue.
Gert, do you have anything to say about this? No. Okay.
Gert Gert not so fast, we are still waiting forth proposer to clarify something from his side. But, indeed I would take it to the mailing list and see what comes out of it.
SANDER STEFFANN: Okay. Those were the two fast ones. Now we go to the next one, which is about ?? sorry, I see somebody waiving.
NICK HILLIARD: Nick Hilliard, INEX, I'd like to take over 2006?05. I think it has merit. Sorry, I just want sure whether you were going to come back to it or not. It has merit. I understand there are some objections. It does come up regularly on the mailing lists and it seems to me that there are valid reasons for going ahead with it and so I am quite happy to put my name forward as proposer for that at this stage.
SANDER STEFFANN: Thank you very much. Okay. So now we continue to proposal 2008?08, which is about the certification of resources. So...
NIGEL TITLEY: I have been standing up on this platform now since, well since 2008 I suppose and giving you progress or lack of progress on this particular policy. So, let's see where we have got to.
Okay. Current version of the policy. This is all about certificates and the RIPE NCC issuing them and all sorts of things and it basically allows you to sign your INET NUMs and so forth to prove that they are yours, at least this is the idea. Of course they are not yours, they are only loaned to you but that's neither here nor there I guess. Ment current version of the policy that I say that certificates are issued on request. They are issued to non ERX address holders, they have 18 months validity which is many to be the one year you pay RIPE plus six months where you forget to pay your bills, they are revoked when the address is reclaimed, okay, don't pay your bills and RIPE reclaims the address, then the address is reclaimed and the certificate is revoked. And it's at the point at which your contract expires and the address is recovered at the opposed at which the address is re?issued. There will be no revocation when the address is under arbitration and it's obviously strongly tied to Address Policy and to RIPE NCC business practices.
Now, this is the policy as it was originally presented back in 2008. And there is been a lot of discussion about it and there are a number of perceived problems with it.
One day we will have secure routing. So people tell me. And when that happens, and if everybody listens to certificates and uses them when building routing policy, only when you have a certificate, or only if you have a row an attached to your INET NUM can you route traffic. So, in theory, if you forget, or delay to pay your invoice and you lose the certificate, then cannot route that prefix. This is perceived as a bad thing. It may even be a bad thing. Also, certificates in theory at any rate, are subject to Dutch law, and if a court order came out to the RIPE NCC and they insisted that a certificate be withdrawn, then in theory the RIPE NCC would have to comply. Now of course Axel has said that he will go to jail rather than allow this to happen and this is grand and we'll all visit him and bring him flowers and so forth. So this may not be a problem.
Okay. But the main result of all this is that the community basically said that they have no confidence in this procedure, this process. And hence, even if we do get secure routing at some point, there will be no deployment. So, the whole thing is a bit of a disaster really.
The RIPE NCC respond to this as follows: Well, all you guys have decided on what the address allocation policy is, and the certificate policy, or certification policy complies with the address allocation policy, okay. So they are only doing what he asked them to. The certificates will be tightly coupled to the registration process and so the certificates are of high quality. You know, we can definitely stay if there is a certificate out there, then it was really issued by the RIPE NCC, the RIPE NCC really knows the owner and you can really trust the certificate, so it's a good certificate. It's not a bogus cheque or whatever.
The whole thing ties in quite well with the RIPE NCC business processes which makes them happy, because it makes them easy to implement. But, you guys, the community, ultimately have the steering wheel. And if you don't want to, if you don't want this policy to run, then this policy will not be adopted. Quite simple.
The basic problem is that the underlying Address Policy or the underlying registration policy, strictly speaking, is both unclear and badly understood. And regrettably, it seems, that some people out there don't trust the RIPE NCC. I can't think why. All good guys, all the rest of it. There have been accusationings of lack of neutrality, not generally from this audience. There has been allocations of lack of competence, again not largely from this audience and there has been accusations of lack of independence, and this seems to be the basic problems, or one of the problems. So we got a bit of a stalemate here. We will be happy, or the RIPE NCC would be happy to issue certificates, but if the community doesn't trust them, then they are not much use. And if they are not much use, nobody is going to use them and so we have a deadlock.
So, where do we go from here? Now, I am proposing some changes, or the CA task force is proposing some changes to loosen up the conditions under which certificates are issued to make, hopefully, it more trustable by the community but also still useful, and so I am presenting a guess, a proposal of what the second version of this certificate policy might be, policy proposal might be.
And, hopefully, will enable us to get some certificates out there. It will hopefully enable us to gain some operational experience. And because the real fix for all this is to fix the Address Policy if it's needed, we won't get stuck into another two?year delay and I shall be still here in 2012. In the medium term we need to revisit the Address Policy, or the registration policy. And then finally we need to bring the certification policy in line with the Address Policy, and that's, again, that's your job. Both of these are your job.
So, policy version 2. This is the suggestion:
Certificates will be issued to address holders on request (as version 1). No charge. These, remember, are only for address that's been issued under the RIR scheme, so this does not cover ERX addresses. They would have a three to five year validity period. So they are no longer tied to the RIPE NCC business practices which automatically makes them of less value, but it seems to address an issue which people have with certificates expiring too rapidly.
There might possibly be a lax renewal policy, we are not quite sure how this would work, we are open to suggestions, it might be easier to get them renewed and maybe it's not tied to the RIPE NCC membership.
And certificates, most importantly, would be revoked on address reassignment. Not address recovery.
So basically the RIPE NCC, when they recover addresses at the moment, which they do, they recover the address, they take it back, and they take it out of the address pool, as it were, and they hold it for between four and six months and they check that that address is not being advertised anywhere in the BGP routing tables. When it hasn't been addressed or advertised for four months or more, then they consider to beth to be clean again and they will re?issue it. And the policy proposal is that at that point, and only at that point, the certificates would be revoked, the original certificate would be revoked. So this is a loosening up of things quite considerably. (Revoked)
So, I have some questions:
Does this address your immediate concerns?
Are we happy to go with this as an interim policy ?? and this is an only interim policy until we fix the underlying address problem?
If there is a problem with the addressing policy, are we all happy to revisit it and check it does what you think it does? Because I don't think many of us actually know what it does.
And, if it does what you think it does, do you agree to a certification policy that does the same thing?
Now, I am a messenger. Rob?
ROB BLOKZIJL: I am not going to shoot at you Nigel. I mean, we spent half the evening yesterday to get you re?elected, so it would be counterproductive to shoot you down.
In clarification, in your presentation you refer several times to Address Policy and sometimes with the footnote actually registration policy. I can fully understand your presentation. Every time I see Address Policy I read it as registration policy. Is that correct?
NIGEL TITLEY: That is correct, yes.
ROB BLOKZIJL: Maybe in future presentations, you put that on your slides, because in two years time from now, we don't have IPv4 Address Policy active any more. Distribution policy.
NIGEL TITLEY: Distribution policy and registration policy, yes, that's correct.
ROB BLOKZIJL: But we do have, hopefully, a registration policy in place and that makes it much easier to explain to people what the role of ??
NIGEL TITLEY: Yeah, whatever it is that's underneath needs to be fixed, yes.
ROB BLOKZIJL: Okay. Thank you.
RANDY BUSH: Even though I live in Japan, I am an American, so if you don't mind, I'll shoot you and bomb your cities.
Could you back up one slide please? ?
Yes, yes, yes, yes.
NIGEL TITLEY: Can it be made a point of record that Randy has agreed with me on four occasions? Gert Gert this must be a bad sign.
AUDIENCE SPEAKER: Hans. Maybe it's a bit of an eye Niamh question, but I was wondering, what's the difference between getting this certificate issued to certify that my address space is mine than getting a certificate issued so that my website is mine? It's kind of the same thing, and it's in the website analogy, it's linked to the business model of the certificate issued, but they solve it by pre?paying. So, if I want a five year certificate, I pay five years upfront.
NIGEL TITLEY: If you want to pay us five years upfront, that's great.
GEOFF HUSTON: Geoff Huston, APNIC. I think perhaps it might be helpful to this community to at least expose some of the thinking that happened in the APNIC area as we designed our certification system.
You say that you are trying to make certificates more trustable.
NIGEL TITLEY: Networks I didn't say that.
GEOFF HUSTON: I actually heard those words.
NIGEL TITLEY: I didn't intend to. What I wanted to make was that certificates of ?? people actually decided they would use them.
GEOFF HUSTON: So, let's understand a little bit about whom are the people who are talking about. Because a certificate is, in this case, something that's issued by the RIPE NCC. Talking about a subject. But its intended use is actually not about the subject. It's about what we call relying parties. Other folk who have to look at the certificate and derive some information that they hopefully are prepared to trust. If they do not trust that information, there is no point issuing the certificate. There is no point to this entire process. So, when you look at it from that point of view, what is RIPE really saying about that subject and their holdings? Now, they are talking about an association of addresses with an entity, in this case you know the holder of a key. If your extending that certificate and you are in this proposal, beyond the lifetime of the current business relationship, you are asking RIPE to make declarations about parties and actions over which RIPE has no knowledge. Think of it from the relying party viewpoint. There are some certificates that reflect an active current business relationship between RIPE and the subject. I like those certificates. I can understand them.
But other certificates that look the same reflect a relationship that no longer exists. How do I tell the difference? Let me posit an analogous situation that occurs in the WHOIS registry. If you look very closely inside the WHOIS registry from RIPE NCC you'll find an entry for network 7 to a holder called half an a something or other. It's not true. (Hey van a) how do you know that all the other entries are good and just that entry is bad? Because it doesn't immediately flag itself as an entry that really shouldn't have got there. When you are starting to do this with certificates, you immediately devalue every certificate you issue, because the relying party has no ability to understand what relationship is being expressed when you issue the certificate.
Now, I could look at that slide that's up there right now and say: If you leave the revocation as it stands, but if you alter the issue around the validity period and the renewal policy to reflect the current business relationship that the RIPE NCC has with the party that is being certified here, I think you would find, then, that you are meeting two goals. You are meeting the goals of the subject of the certificate, but you are also meeting the implicit goals of everyone else who has to look at these certificates and try and understand what they mean. And what you are really trying to do is to change that policy, if I could gently suggest, to reflect a currency of agreement that RIPE is saying something that is true now and true for the validity periods in the certificate. This is the thinking that happened inside the APNIC area as we were designing the certificate engine as it currently stands. And I would certainly urge this community to stand that it's not only whom you are certifying, but the relying parties that actually have to deal with these products who have to understand to what ex accident they can trust these digital artefacts. He also need to take into consideration.
Thank you.
NIGEL TITLEY: We have something on the ??
AUDIENCE SPEAKER: I have two comments on Jabber. One from James blessing from GARU. He is saying you need to keep revocation with reclaiming.
And the other one, sash a look, speaking for himself. He is basically repeating saying, which part of the community doesn't want this needs explaining again. But he wouldn't have a problem if it stays voluntarily.
NIGEL TITLEY: Right. Thank you.
AUDIENCE SPEAKER: Steve Kent, BBN: In response to the gentleman earlier who said why don't we just do this the way web sites do it? There are a lot of good reasons to not do that. In particular, given the range of certification authorities that you find pre?configured into your browser, in some cases it's reasonable to assume that they'll issue a certificate to someone just because they handed them money. They are not authoritative for that information. If those certificates, which are really an attesting to DNS names were issued by the corresponding DNS authorities, that would be reasonable and that would be much more in line with what we're talking about, but they are not, they are issued by thirds who are authoritative for nothing whatsoever. Also if you look at that large list, one of the problems is because these thirds parties are authoritative for nothing, there are no constraints in what they can issue certificates before whereas the RPKI model specifically contrains at each tier in the allocation hierarchy that existing organisation that is operate at that tier issue certificates only for chunks of resource that is they hold. It's a dramatically different and better model than what exists in the other environment, I would say.
NIGEL TITLEY: Yeah.
AUDIENCE SPEAKER: Ruediger: Well, okay. I hate it when confusing things are flown into a discussion. Well, okay, I think sometimes I am a master of doing that myself, but, Geoff, I am ?? I find it very confusing to claim that the RPKI certificates are about business relations with registries. The certificates are about delegation, and the delegation may be there under various forms of business relation, and kind of the obligation of a party who hands out certificates is that, well, okay, the certificates and whatever they are doing about the status of what is certified remains in a valid relationship. So, no, the membership does not really count, the business relation is not certified, relying parties are not interested whether I have paid my fees to anybody, relying parties are interested whether the certificate is validly saying that the NCC handed out that address block to me and they have not revoked it for whatever reason, and at which time, and completely unrelated to whatever the current business relation is.
NIGEL TITLEY: I take your point.
AUDIENCE SPEAKER: Sam you'll wilder:. I heard Geoff saying that if this community adopts this policy, relying parties will have no ability to discern how to interpret these certificates or what the relationships behind them were and I just don't find any merit in that argument. The analogy I like to use is about driving licences or permits. You know, even though the date on it expires it still shows that at some point someone presumably pass add driving test and probably still says something about the identity of the person. There might be still be a reason why you don't want to rely upon that credentials but it still says something of value. And it's perfectly reasonable for this community to say, yes, we like the semantics implied by this policy, even though they differ from the semantics that APNIC chose for theirs and APNIC may well have gotten theirs wrong, we want to do something different.
RANDY BUSH: But also going to speak for a moment with MyAPNIC policy chair hat on. We have passed no such Address Policies. We have not discussed this to any extent within the APNIC policy framework.
Taking that hat off, where this came from was the taskforce meeting, I think it was Monday morning, and the problem is that the relying parties were asking to bet are twofold actually: It's one, and this lies the demain for using certificates for routing validation. Okay. And those people had the misfortune of having to listen to me Monday afternoon know that we have done everything in the architecture to make it so that you don't have to die when that person's certificate gets screwed with. But it's still ?? people are going to be very, very reluctant to play in the routing game. There are two halves. There is the person receiving the route but the person who is saying I am going to use my certificate, I am going to get one generated, we are going to play in certified routing at all. And what we found was that the members, in general, do not really have a clear view of RIPE registration policies and RIPE very much intends to work on that, and until those are clearly understood, that playing bet your routing asses on these better be something RIPE says until we sort this out, we will be generous open and delecate, with no promises past that. I think if you back up one or two more slides ?? this was the problem, it's essentially Address Policy today or registration policy, thank you Rob, is unclear and not well understood.
And until that's true, tieing my routing to that is absolute insanity and I am not going to do it.
AUDIENCE SPEAKER: Axel: I am the operator of a fairly large number registry. Maybe with a slightly different facet. First of all, I like very much that we are discussing this and I think all our understanding is starting to gel and obviously this about a policy development process so you guys decide what we do.
Coming back to operating the registry. Over the last couple of years we have on your behalf, spent quite a lot of resources in improving that registry and making ourselves known as the operators of a fairly strong registry, a good one, with quality in it. And we are not done this. We are still waiting for Phase Three of 2007?01. That is something we have been asked to establish relationship with people who hold addresses and to and reflect that in the RIPE history.
There are quite a number of people out in the world that look at the RIRs as reg trees they can depend on fairly well. And if you go one further, I think, where ?? yes ?? I understand your concern, I believe. The last point on that slide I really wonder whether this community wants to do this, because I think, if we do this, we have two sets of data out there that are not in sync. We have the registry, and at some point in time we receive addresses back from our members occasionally, and that is reflected in the registry. Then we have ?? would have certificates out there that say something different, that would say that those addresses are still given out, still allocateded, which is not the case.
So, I think if that would happen, we would really cast a big shadow of a doubt over what are we saying? What is right, what is wrong?
SANDER STEFFANN: I want to close the microphone after the Jabber comments because we have some other issues coming up.
AUDIENCE SPEAKER: I have another comment from sash a luck say less about this trusting the RIPE NCC, but the attack surface it creates is basically also the political influence, all this stuff, so...
SANDER STEFFANN: In this case, because Jabber was a bit fast, I want to close the microphone after ??
AUDIENCE SPEAKER: Daniel here. Can we go back to the concerns? And I am speaking as a RIPE NCC employee and as someone whose been involved with Address Policy toweley. I think this is uncertain doubt being cast here. What Randy and folks are trying and what this is about is to lure people into using certification by saying oh it's not all that bad, but what's happening on the other hand, is saying well, the underlying data is bad, there is no trust with our own community process of self administration of this or self?regulation, if you wish. I think this is all bad. This is all sending a totally wrong signal. First of all because we are being lured into a sort of a drugs dealers thing saying basically they are not that bad, they are going to be valid for five years and use them. On the other hand, we are undermining ourselves.
We have spent quite a lot of energy in this community and in the RIPE NCC to get the registry better. We did 2007?01. We went through all this pain to establish relationships, to make sure that's what in our registry is good, to make sure that policies are being applied, and now we are throwing it out of the window just for the one goal of getting the routing security thing deployed which will be sued owe security if we do this. I think this is totally wrong, I think we should, from the beginning, follow the registration policy, which is not unclear, which is not badly understood. I would say if you, as a community, trust the RIPE NCC, you should trust the certificates and use them. If you do not trust the RIPE NCC, they'll understand the routing policies, then no expiration period or other watering down the certificates is going to achieve anything.
NIGEL TITLEY: Thank you Daniel.
AUDIENCE SPEAKER: HANS: It seems to me that the whole thing here is about understanding what we are going to use the certificates for. As I understand it, I want to use them in my routing policy to determine if I should accept this route or not. Now, if the criteria for getting the certificate is that this is registered in the RIPE database, could I look it up in the database to check that instead. That's an overhead I don't want in my router so I would like to have tomorrow mechanism in the routing engine to do that for me. If you don't have any expiration or any revocation policy at all, could I build my policy to say well if there is a newer certificate issued I would accept that before the older certificate and you could do things like that. So it's really a matter of do I want to outsource my whole trust or routing policy to the community or do I want to build this myself? And maybe we need to think through several types of certificates. Some says that yes, this is a certificate with a valid business relationship. Some people will trust that more. And others certificate type says that this is actually what's registered in this database and it's valid for five years and we don't do anything more about it. Maybe one needs to think broader about this so that you can actually open for different kinds of services. So maybe that's a solution to the path forward so to get it started.
AUDIENCE SPEAKER: Ruediger: Daniel, when you say we are seeing fat around the arguments, yes, I agree and I hate that. The thing that I would see is, well, we need, instead of kind of doing fuzzy remarks about well, okay, things are not trusted and so on. Well, okay, we need to actually and explicitly pin down all the parts of the policies and well, okay, the critical thing is not the high frequency allocations, the critical thing is how are the many different cases and reasons for revocating an allocation are hand. I am sure there are quite a number of open ends in the definition of the policies and the procedures used there, and well, okay, if we can have that pinned down correctly, and that needs to be done I think there will be absolutely no problem in revoking certificates at the point where the well defined due process based policies and procedures have revoked the actual allocation. For Axel, I could say, well, okay, damned this. Taken together the obligations of a certification authority that handed out the certificate, together with a policy that says well, okay, only when the thing is reassigned the certificate can be withdrawn actually brings you in a hard spot because cannot revoke things that have the certificates still out there. So, well, okay, you could issue this as a very devious trick to force you to define clearly the revocation practice.
NIGEL TITLEY: Can I just ask two questions to try and get some clarity on this? I would like a show of hands on these please.
Those present in this room, who would be happy with certificate issuance tied to RIPE membership, RIPE NCC membership? So those who are happy that certificates will be revoked when your membership expires? (Revoked) does everyone understand that?
The second question is: Certificate revocation: Would you want it done at reclaim, at the point at which the IP address is reclaimed or the point at which the IP address is re?issued? Those are my two questions. That's all.
The question number 2 is: Do you want the revocation done at reclaim time? Okay.
So the first question is:
RANDY BUSH: Could you define that as forced to reclaim as opposed to Axel was saying was ??
NIGEL TITLEY: Yeah, forced reclaim. Okay. First question:
Certificates are issued and expire in relationship to your RIPE NCC membership. Okay. So if you stop paying your bill, a short time after that, your certificates expire. Okay. With all the safeguards that we have talked about, arbitration and all the rest of it. Is this room happy with that statement, yes or no?
Yes?
No?
I'd say that's about equal. So we have got no consensus one way or the other.
Okay. Second question:
Certificates are revoked when the address space is reclaimed as opposed to re?issued. So reclaimed. (Revoked)
Can I have a show of hands?
Okay.
Re?issued? Okay. Thank you we have a clear majority for reclaimed there.
Thank you very much indeed. I don't know how much further we are forward. But we shall try. Daniel?
Daniel: Can I ask one more question which is maybe not sort of loaded. Who in the room would be happy with the certification be very closely bound to the registry and the policies that govern the registry which we already have?
NIGEL TITLEY: Yes, that's a good question actually. It's a slightly less loaded version of my first question.
Daniel: That's why my asking.
Ruediger: Without clarification of the reclamation.
Daniel. This is not true Ruediger. It is clear.
RANDY BUSH: Why did you and Rob propose discussing it?
Daniel: We propose to take it out of all the other aspects which will not be relevant any more once we are not allocating any more. But it's clear enough, and this is the uncertainty and doubt that's being cast here, is basically saying how this is not clear and da, da, da. What you are doing here and what everybody should be concerned about it if we are having this discussion and somebody outside, and very notably somebody who is concerned with public policy sees this, we are weakening our own self governance by putting up slides like this and having a discussion like this because the conclusion will be our procedures are weak and we don't even trust ourselves.
RANDY BUSH: Talk about fud.
ROB BLOKZIJL: I think the current policies are clear but they are by far not complete because they don't cover all the existing IPv4 address space and I personally hope that we come with a much complete err registration policy.
RANDY BUSH: The problem is globally the operators have, excuse the American I had item, voted with their feet. The registry data are not used for routing in the vast majority. And all this proposal, Phase Two of it, is that
Daniel, they are two different database ?? this is Daniel, it's quite obvious to everybody in the room that if two registries are on the same database, it doesn't make them the same registries.
SANDER STEFFANN: This turns out to be a difficult subject.
NIGEL TITLEY: This was a five minute presentation. I am not at all sure, I don't think we have actually moved much further forwards to be quite frank. I think we are going to have to, as usual, shift it to the mailing list and let's see if we can get more clarity on that.
SANDER STEFFANN: I think that's the best option.
NIGEL TITLEY: Right. Thank you.
Okay I have another presentation. And it's, hopefully, it's slightly less controversial. But then it may not be.
I shall be a little bit quicker, I hope.
2009?01. This is a policy that's been hanging around since the beginning of 2009, what a surprise there.
And it's a global policy and it's pretty well gone through the mill throughout the rest of the world, but it still remains for us to take a decision, and if possible, I'd like to get that wrapped up today.
This is a quick outline of the policy. It's a global policy, as I say. And it's to do with what do we do with the dribs and drabs of the addresses that are reclaimed as IPv4 runs out. Okay. Phase 1.
We establish a central IANA pool for small odds and sods of address space, and certain classes of recovered IP address spaces are mandated to be returned to IANA. Okay. This is address space that's recovered which RIRs and it provides a mechanism for them to be returned to this central pool. Be done on a 6 monthly basis and they be aggregated into /24 blocks. So hand back anything smaller than a /24. At the moment there is no way of handing back anything that's smaller than a /8. So this is the first part of the policy.
Second part of the policy: Once the IANA main pool is exhausted then RIRs may apply at 6 monthly intervals for dribs and drabs of address space from this pool. Okay.
Global status: LACNIC: Adopted.
APNIC: Adopted.
AfriNIC: Adopted.
ARIN: Adopted but they changed, effectively they changed one word in the text which means that recovered address space is not mandated to be returned. Okay. There is actually quite a good reason for this which I'll go into later.
And RIPE: Well we still haven't made a decision. It would be ever so nice if we could decide one way or the other.
A little bit further explanation as to exactly the changes that ARIN made.
They said, with a certain amount of justification, that this is actually two policies rolled into one. The first policy is the establishment of a central IANA recovered pool, something we can put these slimey bits of water down at the bottom that we have scraped out of the bottom of this barrel which full of newts and frogs and somewhere we can put them and the other policy is, the return of recovered space. What actually gets done ?? what happens when an RIR recovers space? What does it do with it? And it's two policies and ARIN said this is a regional concern, and it should be dealt with regionally. And of course when you say that sort of thing, there are possible connotations and as I say, probably unjustified.
So, we have four possible options.
We can adopt the original wording, which is what three of the other regions have done. We can adopt the ARIN wording, which is what ARIN have done. We can adopt our own wording, which I hope to goodness we don't do or we can reject T which again is a perfectly valid thing to do.
This has been knocking around on the mailing list for the last couple of months. There is been considerable discussion and the mailing list consensus seems to be to adopt the policy with the original wording.
Now, even if we adopt it with the original wording, the change in the ARIN region makes it sufficiently different that we no longer have a global policy, and therefore it will almost certainly be thrown out by the ASO, even if we presented it to them. So, for this to become global policy, either ARIN changes or the rest of the world does.
You know, either of those things could happen.
And the other alternative is that we split the policy into the global and regional and start again. But, whatever happens, we need to move quickly, or shall we just switch off the ventilator and let IPv4 die to be quite frank is the other possibility. By the time we actually get another regional policy run all the way round, then IPv4 will probably be dead anyway.
So, what shall we do?
AUDIENCE SPEAKER: HANS: We have discussed this a bit in the address Council already and you are quite right to expect that if the five regions don't agree on the common text, we have no option to approve it. We have to return it to the NRO, that will have to return it to regions, so this needs to be sorted out before it comes to us.
The other part of the discussion that we have had in inform Ally among some of the address Council members is what is global policy? So I tried to look it up in the MoU between the RIRs and ICANN and if I am able to find a text here, it says that:
"Global policies are defined within the scope of this agreement and ?? Internet number resource policies that have the agreement of all RIRs according to their policy development process and ICANN and requires specific actions or outcome on the part of IANA or any other external ICANN related body in order to be implemented."
So with that definition if we focus on required action by IANA, maybe we need to sort of look into which part of the policy proposal that needs that and what part of the policy proposal that doesn't need that, and then come with refined proposal that focuses on the global policy aspects.
NIGEL TITLEY: So that's effectively splitting it into the two halves. I am inclined to think that that's probably the long term way forward, but as I say, do we switch the ventilator off on IPv4 all together? John?
AUDIENCE SPEAKER: John Curran, CE or of ARIN. I am going to try to provide information that will help this discussion. First item is that it is almost inevitable within the ARIN region that there will be address space returned which would be applicable to this policy and even right now the historical tendency in ARIN has been we have actually taken all the address space of /8 size for example and directed them to IANA to return them (for example) without a good policy, the second portion of this policy, the IANA is somewhat time he'd how it's going to handle smaller than /8 and how it handles /8 would be a unilateral assignment to RIRs right now without this policy. With this policy it will be an even decision, to the extent that this region does decide that it's not going to proceed on this policy either original text or ARIN text and decides to abandon, the IANA probably is going to be ham strung unless someone introduces a global policy that allows for hanling returned blocks. That's just something to consider, because it will be the next question on the table.
Two other things. You noted that ARIN, in the ARIN region this was considered a local policy matter whether to return blocks to the IANA. That is true, there is probably an undertone that isn't well communicated. Again the practice has been and without direction from the community through our advisory Councel or the board, we'll to do so but the question would be at some point in the future, let's say one RIR decides for the space that it gets from this policy, it decides to hold auctions of that space. That might cause paw pause in any region whether they wish to continue to return space if we have completely departed from need base, and so, it was the fact that we have worked on a need base principle we are probably going to end up someplace else, but how we manage that transition unilaterally returning space presume that we are all using the same framework and in the ARIN region there was concerns that some regions might change their framework faster than others and not make a return make sense and delete that flexibility. It's not, per se, a statement of intent. It's a statement to have the flexibility.
At the end of the day, if this region moves to the ARIN text, of course I'd recommend everyone go encourage the other regions to do that. If you stay with the RIPE text, and keep the proposal, I'd recommend you go back to ARIN and explain why, because the ASO also is, as noted earlier, kind of completely blocked on this unless we get resolution.
NIGEL TITLEY: Okay. Thank you, John. Rajaul.
AUDIENCE SPEAKER: Rajaul from LACNIC, one of the authors of this ?? I am one of the authors of this proposal. I think that Nigel has stated very well what are the options that we have. One of them is I think that is the best one is to try to work in a new proposal. In fact I think that's ?? those of us that use it to be involved in the collaboration of this proposal could work together to have a new proposal and to feed the expectations, or try to accommodate the expectations of everybody.
But, as one of the authors of the proposal, I think that my personal view is that it would be good to finish the discussion of this proposal in other regions. I think that will help us very much in order to know what is the sense of all the regions to start the work to any one.
I think that some of the concerns that have been expressed in ARIN could be accommodated, others I think that will need more discussions. I think it doesn't matter if we it is mandatory or it is volunteer, but I think it would be very bad for the global addressing community if we see in the future that large amounts of addresses are returned to one RIRs an those addresses are made available only forgiven region. I think that's ?? I think it will be very difficult to explain to all stakeholders and more difficult to explain if those addresses belong to the addresses that we name as legacy addresses. So I think that will be very difficult to explain, at least in my region, to all the stakeholders, including governments. So I think that's the way ?? the way you have in mind maybe, I don't want to speak on behalf of you, but I think you stated as one of the possibilities I think that the way is that is to work together in order to get a new proposal.
I don't agree exactly with the statement that the address councils blocked on this issue, because formally the discussion has not finished yet in all the regions (Council) so I think that we are still in the discussion phase and what the councils doing is just following what's happening. I think when the discussion finish in all the regions, so we will have the opportunity to say oh yes, we have a common text or we don't have. I think the address councils trying to anticipate what will happen and I think that is very firm, but I think that we still have to discuss a bit more.
WILFRED: I'd like to echo some of the stuff that Rajaul has just said. The issue is not really that we have, we as the address Council, have to go out and find about the different versions in the different regions, but rather the process expects that if I am right, the NRO, actually sort of forwards the global policy that was decided in all the five regions to the ASO and the task of the ASO then, or of the address Council to be more precise at the end, is just to rubberstamp the fact that the policy process was properly followed in all the regions. The real catch is that if the, if there is substantial differences in the wording within one or more than one region, then it should not even be forwarded to the address Council for rubberstamping, and with that background, I would actually encourage this region to decide and it may sound blunt here, but I really mean, it decide on whatever you want. It doesn't make a big difference procedure wise. Because as soon as we, as the last region, have actually decided on A, B, C, D or X, we can have the machinery start to work. We can actually sort of get the NRO involved in trying to do whatever is possible or not, or we really have the fact on the table that this is not going to be global policy. So, we can actually see the need to start with something which is feasible, which is better, which is more fit, whatever the term is, and which may be agreed sort of within the time frame we have got. Sort of the landing err we drag our feet, the bigger the chance that whatever we decide becomes irrelevant and becomes more and more difficult to repair in the end.
NIGEL TITLEY: Jabber channel.
I have a question on Jabber from James blessing, GARU, actually directed to ARIN. Could you review and potentially adopt the original text maybe?
SANDER STEFFANN: I see John walking up to the microphone behind you.
NIGEL TITLEY: I haven't got the original text.
AUDIENCE SPEAKER: John: The question is as I understand is there a chance that ARIN could adopt the original text. Well the original text went through the ARIN consideration process and got modified in that process. So ?? and we just had a policy meeting in Toronto, with we had our public policy meeting three weeks ago and the state of this was fairly well known. I guess it was understood that RIPE was still considering this, but it was known in the other three regions that the original text was adopted. There was no motion in Toronto to, in light of that, go back to the original text. I am not saying that it couldn't be reconsidered. In fact, I encourage the community obviously if you do stay with the original text and maintain the policy, it will be necessary to go to ARIN and discuss it. But I will say the record for why ARIN changed the wording and the reasons why, to my knowledge, still remain. So those would need to be overcome and right now, if it follows the same consideration thought, it will not pass with the original text.
NIGEL TITLEY: So, as I say ?? sorry, Hans.
AUDIENCE SPEAKER: HANS: Yeah, I was thinking of modifying my previous statement a bit. Because maybe, if we look at tactics here from the RIPE region, we could know either discuss this, come up with this proposal or that proposal and spend more time on this, or we could simply move this proposal to last call, call for consensus and then it's out of our policy proposals process. Then we have done our job in this forum. If we want to take ARIN's proposal we probably formally have to insert a new proposal. So it takes a longer time. If time is a matter here, the way forward is simple. If the community wants that.
Now, that will leave the NRO with an interesting challenge and maybe this could be an interesting test to see what the NRO will do then when they have different texts, because then they will have to do something. And then we can wait and see what that will be and of course the outcome that have can be interesting to discuss at the future meeting or at the mailing list but at least that would move us forward. And I think the more I think about it, if I take off all my hats or previous hats, I think maybe action here is the thing. We need to do something. We can't wait for that many months or years on this. So let's move forward, my motion would be approve the original proposal. If we listen to what ARIN said, there is some merit to that as well so maybe we should sort of stick to and add some advice to our RIR maybe they have thought of something clever so maybe it's possible to get the modified version with that in, but how can we do that in the shortest amount of time? I don't really know but it could be interesting to pass that challenge to the NRO.
AUDIENCE SPEAKER: Rajaul: Just a comment, a brief comment. I think that it is not really a bill challenge for the NRO. I think what we need is to finish the discussion on this proposal in every region, and so after that, we will say, okay, we have potentially we have the possibility to get an agreement. When I say "We" I am referring to the authors of the proposal. So we are the ones that had to be involved in working in building the consensus if we want. If we don't want to do that, so there will not be a probably a proposal that is able to get consensus. But, if this proposal, the regional proposal is approved in RIPE NCC region, so we have to go back to ARIN. If there is no good reception to this proposal there, so we would have to work on a new proposal. End of story. If we want to do that, we will do that. If we don't want to do that, so there will not be any global policy on this issue. So I think that is not really a big challenge. If it is not ?? if this proposal doesn't pass in RIPE NCC region, so we will have the to start the work earlier in getting ?? we will probably not wait until the next ARIN meeting so we will start to work on the new proposal if we want. It is very simple. I don't see it as a very challenging thing. I see this is more of ?? it's a challenge thing for the willingness of the authors of the original proposal.
SANDER STEFFANN: I want to close the microphones after the current queues, because we still have two items left and ten minutes. So please keep it short.
AUDIENCE SPEAKER: Thank you Mr. Chairman for pointing out that this is, indeed we have got ten minutes left and two presentations because that was the one point I was going to make. The second point I was going to make is that consensus is reached on the mailing list and not in this room. Thank you very much.
SANDER STEFFANN: And Gert reminded me that there seemed to be a lot of voices saying, like Hans pet err said to move it forward in the process and get consensus on it.
AUDIENCE SPEAKER: Dave Wilson, address Council member. Personally I like the proposal as is. I have no big problem with T but I do have one question. And that is: It's been identified that there is a global portion and a local portion very well. Let us assume for a moment that we adopt the original wording. Let us assume as well that ARIN decides to adopt the original wording, just bear with me for a second here. Let's assume then that it is adopted as global policy. If a region later decides, any region, I don't care which, decides to implement a local policy that conflicts with a local part of this policy, can anyone tell me what happens then?
SANDER STEFFANN: Very short please John.
AUDIENCE SPEAKER: John: It is because of the MoU that creates the NRO, and our agreement to have global policy, and to run that policy not only through all the RIRs but through ICANN, it's not proper form to create local policy on top of global policy. I am not saying it can't be done. Because every organisation an autonomous, but it doesn't bely the original intent of the MoU to cooperate. So things that end up in global policy should be changed through the global process, if you follow the intent of the MoU, that's only ARIN he is reading of it as we take it.
SANDER STEFFANN: Then, I want to close this topic for now and suggest we move it back to the mailing list.
NIGEL TITLEY: On which there is consensus I would say.
SANDER STEFFANN: Yes, that is my feeling as well. So, then we can continue with the next topic, which is the open policy hour.
Here we are. Gert has actually an item now, so we will be getting a Skype presentation, or at least comments. It's about the difference in the policy text between the, how the 80% rule should be applied, and I think that the best way forward would be to let Gert take it from here.
Gert Gert I propose that Sander would do it because it would just be quicker but since you want me to do it, I will try to just present what this is about and then we'll take it to the mailing list.
At the last meeting, we asked Alex from the RIPE registration service to point out problems with the current policies that the registration service is experiencing, and one of the things that they noticed and they had discussions with LIRs about is the 80% allocation rule. These two slides, this one and the next one are actually the slides used by Alex. There is ambiguity in the policy text of the IPv4 allocation policy about whether if an LIR has multiple allocation and is coming back for more address space, whether ever single allocation has to be filled or the grand total of them.
It's in the policy text, there is two sections that talk about 80%, that's 5.3 and 5.4.
5.4 can be interpreted as every single allocation has to be filled by 80% or more. While 5.3 is pretty clear that it's talking about the grand total of all of them. This makes a difference if an LIR has something like a /16 and a /19. The 16 is filled up to 90 percent while the /19 is only at say 70%, they might have arguments with the first interpretation of the policy.
After the last RIPE meeting, I have brought this up on the mailing list, and asked for comments, how we should proceed with with this. On the specific topic on the 80% interpretation, there were a few voices that said 80% of the grand total is what the policy should be. Nobody said that the other interpretation is what it should be so just leave the document alone. Nick Hilliard brought up the question how useful 80% is as such, which wasn't exactly the topic of the question, but Remco will touch on this right away. And my personal comment about this is that, well, I am the culprit who wrote 5.4 about nine years ago, and the only reason why it contains the reference to the 80% rule of to emphasise the 80% rule in 5.3 and not to create ambiguity.
So a couple of voices to just remove the ambiguity part in 5.4.
Next slide: This is what I am proposing to do as a formal policy proposal change: Remove the ambiguity. Don't tackle the question whether 80% is a useful may trick or whatever. So if you look at the specific policy text here, this is the text from section 5.4. 5.4 talks about be sub?allocations and it has this sentence which is in italics "LIRs are still required to demonstrate about 80% usage for all their allocations" and the "All" here is causing the confusion.
My proposed text is just so remove this sentence, leave everything else as it is which immediately removes the ambiguity because there is no reference to 80% any more.
That's pretty much so far. As we are running massively out of time, I would propose to have one or two questions or comments and then follow up on the mailing list. I will make this with the help of Filiz, a formal policy proposal, with me as the proposer. So I am taking off the Working Group Chair hat and Sander will oversee the process then, so it's definitely useful to have two chairs for a situation like this. That's it from my side. Any comment?
SANDER STEFFANN: I see two people walking up the microphone. Gert Gert okay. Gets have two comments and move on to give Remco sometime.
SANDER STEFFANN: I will stay out of this discussion and let Gert do it, because I will have to declare consensus later on, so I won't be involved. Gert Gert you need to steer the discussion.
SANDER STEFFANN: Yes, but not in the content.
AUDIENCE SPEAKER: Nenagh: I just want to support this very, very firm. I think it's a good way of clearing thing up and I think, I think the 80% rule and the ambiguity and the way it has been instigated has made a real hard time for people with old address space like myself. Thank you.
AUDIENCE SPEAKER: Alex: I agree with Hertz that making this change would make the pole see extremely clear about what's intended. However my original question was about the interpretation. And looking at what's been said in the meeting and what's been said on the mailing list, I think the general opinion is pretty clear about what interpretation we should actually use, and we will begin to use that interpretation as quickly as we can, which should be fairly quickly. Gert Gert thank you. I am off now again and go to Remco.
SANDER STEFFANN: Thank you. Remco. Sorry for giving you like one minute, but we will run into the the break a bit. REMCO VAN MOOK: So, you guys figure you could get a way with a RIPE meeting without me presenting, so here I am.
And I thought let's talk about a controversial subject because there hasn't been any so far. Well...
So sorry about this, I think we are going to run into the coffee break a bit. How much, depends on you. I think we might run into it quite a bit.
So let's talk about 80%. Going real quickly through all of the policies worldwide related to this. This is the RIPE policy.
This is AfriNIC policy. Remarkably similar.
This is ARIN policy, 80% again.
APNIC policy at least 80%. And LACNIC policy: At least 80%. Where does that come from, what is the origin of this?
This is the first piece of lets say co?ordinated policy worldwide ever. And why is that? Basically because everybody copied the RIPE documents at some stage. This is the first document that actually described any sort of rate of limit of threshold. RIPE 159 out of 1997 which nearly used up between brackets about 90%. And then a year later RIPE 185 states "Is nearly used up (about 80%)" so something changed in that year and that was probably because people felt that 90 percent was a bit too high. So ?? and that was accepted as policy and has been going on for many, many years.
Many, many, many moons later in 2005, somebody, I think an a person present in this audience, came up with a policy with an HD ratio with made a sliding barrier on the threshold, giving it a 71% utilisation limit for a /20 down to 57 percent for a /12. The mathematical formula behind is is pretty much like the contributions for the RIPE NCC. After a lot of discussion that one was withdrawn.
What we can conclude from that is that 80% is a bit of a sweet spot. On one side technical and administrative costs is not too high. 95 percent as we can see from historical documents is a bit too high and 70% or less was deemed too low by the community.
So, basically, striking a balance here. But what if that balance dips? What have technical, administrative costs and conservation and aggregation, that balance changes and why would that be? Well I mean conservation and aggregation go out the window if you don't have any new blocks to allocate any more. So, what if that gets replaced by unavailability? So, this is your typical graph of how it probably works for, well, roughly the community right now. It's conservation on one side and costs and it's the intersection of the two graphs and that's why we end up with 80% right now. But cost versus unavailability is a different graph all together and I have tried to put it in like this. Basically my assumption is that you'll want to continue selling your stuff using IP addresses for your end users until there is no more profit in doing so.
This is what your boss thinks about this. The basic premise is: We are losing money, help. This is what the accountant said. He says well we can create up to 20% of additional Revenue if we go about this a bit smarter, and if we don't have anyways to grow this business, that's a business risk that we should disclose in our public filings. Oh, dear.
So, with with many thanks to Geoff for collecting the data, I have taken a copy the data of March 21st I think, Geoff. So this is what the ?? well you have seen this picture before. And I have decided to put in another line on top of this, and blot out some other ones. So, this is the result, ladies and gentlemen, of the 80% utilisation criteria. There is wasted LIR space, space that we have agreed not to, well, sort of use, or at least not required to be used. And currently that is about 21 /8s in total space worldwide. Assumptions behind this is that well large RIRs get new space, well this is all pretty much documented. The main assumption here is, and this is ?? so this is an optimal one. This red line assumes that every single LIR in the world is currently at 80% utilisation, and basically can request full new address space today. And so it's probably a bit worse than this.
And I didn't make any distinction between PA and PI and everything was marked legacy on the IANA record I have taken out of consideration. So this wasted space is out of the RIR policy allocated stuff only.
So, currently a minimum of 21 /8s that we're now wasting I think is the proper word, that currently exceeds the unallocated IANA space and at the rate we're going, at deletion, this will have increased to 25 /8s.
This is what it's going to look like for the outside world after deletion, there is well some bits left in final /8 policies that some newcomers might get access to, and there is the current LIRs who will be sitting on an absolutely pile of address space, whether they'll be able to use it or not. So this is not an issue if we are one hundred percent certain that even after deletion we still won't be able to use this space at all for anything ever. But, is that really the case?
If not, then this is going to look very, very bad for our open transparent bottom of policy process because everybody out in the outside world can point at us and claim that we are being greedy. And probably have a case there.
Is this still fixable? Well has Nigel indicated earlier, it's not too late, but we are very close to do anything with policy which relates to IPv4. We can ?? the only way we can do this, as far as I can see, is change the utilisation criterion globally while we can still expect the LIRs to come back for at least one new allocations for the RIRs are deleted of address space. The real challenge here is what should that look like?
AUDIENCE SPEAKER: HANS: I don't think you did your research properly. RFC 2050 is actually the source of this 80% and it's published a bit before those dates that you referred to. That's the first global policy on handing out addresses from IANA to RIRs.
REMCO VAN MOOK: That's interesting, I tried finding it in 2050, I couldn't find it.
AUDIENCE SPEAKER: Hans: It's on the bottom of page 5. But if you think about it it probably has its origin but this is speculating not doing research back to beginning of 1900 when a guy called Pereto, invented the Pereto principle with the 1820 rule. That's probably why that number was picked. So get to the real issue: Should we increase it? Yes, I suggested that to Wilifred earlier here today, that maybe we should make a proposal to increase this to 85 percent. On the other hand, I don't think we will actually finish that discussion before we have run out of IP addresses so I think we are probably too late. REMCO VAN MOOK: That's exactly the reason why it wasn't a policy proposal.
AUDIENCE SPEAKER: Nick Hilliard: I was just going to make the point that Hans pet err made there at the end that changing this policy is actually only going to have an impact if there is IP address space left in the RIRs to assign or to allocate. So, if it's going to be changed, if needs to be done very, very soon.
REMCO VAN MOOK: Absolutely.
SANDER STEFFANN: I think I would like to see a show of hands on how many people think we should do something about the 80% or how many people think this is not useful any more.
REMCO VAN MOOK: Let's carve this into three sections. So, one is: Three potential answers. One it's too late so mess with this anyway.
2, is yes we should try to change it or no, I can't be bothered.
So hands up for: We are too late for this anyway?
Thank you. Quite a few hands.
Who says yes?
Also a few hands.
And who says no, 80% is holy and you shall not touch it?
That's not unexpected.
Okay. With that, I'll run off stage again before I get hammered with toe mate owes. Thank you.
Applause)
SANDER STEFFANN: Thank you Remco.
Okay. Officially we now have any other business. Does anybody want to take up more coffee time?
Okay then. Thank you all for your participation. Get some coffee and until the mailing list and the next RIPE meeting.
(Coffee break)
LIVE CAPTIONING BY MARY McKEON RPR
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE