These are unedited transcripts and may contain errors.
The session on address policy resumed on the 7th October 2009 at 11 a.m.:
CHAIR: Welcome back to the Address Policy Working Group.
We need a couple of seconds for everybody to find a spot and could calm down a bit. The first session this morning was pretty much presenting from the stage where we are, what options we have. This slot will have heated discussions about how you think that things should be. As always, please remember the webcast.
This is a interest additional item on the agenda where I tell you about the new proposals that have come up since the last RIPE meeting and that we need sort of discuss first time on an address policy meeting in person. Actually they are none of these, because all the proposals that have come up since the last RIPE meeting have actually completed already. So this emphasises the point that I always make, no decisions are made at RIPE meetings that we can actually get policy proposals through in between RIPE meetings if people agree that this is the way forward. So, what we have today is all the stuff that we have not been able to reach consensus on yet, and that needs more discussion and more guidance.
As I said, no decisions are ever made at meetings, because, by nature, the number of possible participants at a meeting is limited, while everybody can reply to the mailing list. The purpose of the meetings is to sort of quickly collect feedback, get an idea where the Working Group is headed to and then discuss the issues on the list, and get consensus there.
If you come up to mention something, please speak to the microphone. Please mention your name, and if you think it's important, your affiliation and please remember that people are listening to the web stream and they can provide feedback by Jabber.
So, going right to the first proposal. This one has been sitting on our plates since a long time. It's from 2006. The gist of it is that people want independent address space. People want this independent address space to be routable. They have only five machines, so technically, they qualify for a /29, but the operator community seems to agree that a /29 is not routable globally. So people today have the opportunity of not using independent address space, which might be the right thing to do then, or to lie to the RIPE results list and say I have 200 machines, I need 24. And then they get a /24, that 24 is routable by sort of majority consensus today. Having a policy framework that will sort of regularly make people lie to the RIPE NCC is not considered a good policy framework. But, at the same time, this proposal to change the policy to, if you say I have routing reasons, you get a /24 no matter how many machines you have is not getting consensus either, because half of the comments on the mailing list were: Yes, this is the way forward because lying to the RIPE NCC is bad. And the other half of the comments were: We don't want routing reasons in the policies. Or we are not the routing police, we can not guarantee that this is routable anyway, so there is no consensus on this thing so far.
The second problem with that is usually if a proposal really gets stuck like this, there is a proposer around to takes care of this and talk to his people and tries to find a way to reach some sort of agreement on how things could go forward, and with this specific proposal that the proposer, threw it into the pool and it disappeared.
So, what I am suggesting to do here is if somebody thinks this is something that needs to go forward, I would welcome a volunteer to pick up this proposal as proposer, and drive it and try to figure out what's needed to get consensus on this. If nobody steps forward, we would just drop it. That means withdrawn, no consensus, no change to the policy.
If you want, we can have a few comments here, but basically we have discussed the content for a number of rounds without reaching consensus, so there is really more a matter of procedure on how to go forward. I see Rudiger walking to the microphone.
RUDIGER: Excuse me, I probably have stayed too long outside for coffee. Dropping this proposal means there is no way to say "Get me a 24."
CHAIR: You have to claim that you are going to need more than 128 machines in the next twelve months.
RUDIGER: And that would be actually a change compared to the practices that are used so far? Which would be a question to the RIPE NCC.
CHAIR: If we don't do anything, I have been led to believe that there is a number of PI requests that are sort of questionable, but the numbers seem to be sufficient to justify a 24. Maybe Alex, do you think you could comment on that?
ALEX: The PI request for a /24 and our earlier current policy nodes to justify 64 IPs because that's the immediate needs and there should be 50% use after one year and the full thing is generally used after two years because we have a two?year assignment period. And many of our PI requests justify 64 IPs, either by having a lot of machines or having machines that need lots of IPs. Whenever we are in doubt that the request isn't entirely truthful, we will ask a lot of extra questions, ask for equipment invoices and that sort of thing. But, if you look at the numbers of the assignments size or requests size distribution, there is, strangely enough, a sudden cut off at the /24. For example, so far ?? well, these numbers are a few months out, or a few weeks out of date, so ?? but they'll illustrate the point. For example, we have 230 /22 assignments. We have 322 /23 assignments, or requests. And we have 575 /24 requests. And then we have 7 /25 requests. I am not sure if that is proof that there is something wrong, but it's interesting numbers anyway. So, it seems that most requests for PI do take into, seem to somehow take into account that there is a minimum size which is routable in the world today. Does that ??
RUDIGER: Okay, what I was looking for was whether the current practice on the RIPE NCC side was being a little bit liberal in such cases, and what I am hearing, no, you are not really that liberal, but parties are giving you a view of the world which seems to be twisted.
SPEAKER: Well, parties give us a view of the world, and we try to use the tools that are at our disposal to verify whether this view is correct. But then if you look at the size distribution, there seems to be something strange going on.
AUDIENCE SPEAKER: Okay. So by dropping the proposal, nothing is going to change as far as we can tell, and I would say it's a good idea to drop it because as we are going to really see the address pool go away, all such requests, if they want to do something reasonable, actually will have to do something where the minimum number gets deployed and some other technique than routing tiny spaces of address space probably will have to be used formality only and it probably ?? well, okay, it would be nice, though quite unlikely if, say, from some routing group we had some suggestions how to do the multi?roaming in cases and other usage of independent fixed address space that do not need the 24. But ?? well okay, so drop it.
CHAIR: Okay. So, that's what I am going to do. I will announce this to the mailing list that unless somebody steps up who is really going to drive this, we will drop this due to there is no consensus, which is the way the PDP works, if we have consensus we go forward, if we don't have consensus, we don't.
AUDIENCE SPEAKER: Since nobody is speaking for it, I would kind of claim we might have consensus to drop it.
CHAIR: But we are not making decisions here. So the decision needs to be communicated to the list.
AUDIENCE SPEAKER: My word was "Might."
CHAIR: We have another one that's not that old but also getting a bit old in the teeth, which is not proceeding as well as we could hope for, meaning it's coming back and back and boring you. This is Philip Smith's proposing something that has been accepted in the APNIC region. That's the ensuring efficient use of historical IPv6 resources. The two main things that are in the policy text are in there, but the gist of it is that if a new LIR shows up and says we need address space, we don't have any, they are asked to sort of, if they have non?RIR space from older times, they are asked to provide documentation on that and they are asked to show that it's full, that it can not be used for what they are planning now. And if they come up for an additional allocation, that also the 80% usage rule applies to the pre?RIR space. I think the wording of the current text is not perfect yet. We have seen fairly few comments on the list. Some have said this is good, go forward. Some have asked for clarifications and some were doubtful about the specific way to go forward with it. Right now it's at the end of its discussion phase, so it's up to the Working Group chairs to decide how to go forward. And what I am planning to do is discuss with Philip Smith about some details in the wording, some details in the feedback and then do version 4.0 and then rerun it through the list and then either come to a conclusion or drop it. It has been a bit slow because, well, it's sitting on my desk since six weeks or so, and I got a bit bored by this old one as well, so blame me. Peter.
PETER KOCH: Peter Koch, DENIC. I speak as a concerned member of the Working Group chair's collective which has to judge the following process and consensus during the PD D, and I am referring to something that probably was previously when Ruidger suggested if nobody is speaking in favour of this, we might draw this and that conclusion. I would just like to remind the community that it's very hard for the Working Group Chairs collective to make these decisions regarding following processes when there is sheer silence. So if one is really in favour of dropping a proposal, they should say so, as well as people who are in favour. But we need more voices being raised. And that is not just me, but of course informed consent is better.
CHAIR: I agree with you that it's useful to have more voices from the audience. For this specific case of just dropping a proposal where we had lots of comment and we obviously have no consensus yet, I think this is something up to the discretion of the Working Group Chair in question in cooperation with the proposer. But the proposer went away, so it's now ??
AUDIENCE SPEAKER: Sure, it was more a general remark.
CHAIR: In general, I fully agree with you.
WILFRIED WOEBER: Wilfried Woeber, speaking as a local registry manager. I think we should still work towards that direction, which is outlining the proposal.
CHAIR: This one?
WILFRIED WOEBER: This one, exactly. Although, my feeling is that the proposal as it is structured right now, does not properly take into account that in some pockets of the world there are big amounts of address space which are legacy and they are not LIR. So in our case the amount of address space that we are managing in the framework of the LIR is very, very small compared to the address space which is used by our customer collective. And I do not expect many or all of those institutions, universities, and research sites to become an LIR. Sort of that should be structured in a way which removes dependences on a particular service agreement on a particular legal relationship. It should just be a site or a customer or a user, I would have to come up with a better term for that, is required to disclose the use of existing address space before applying for additional a disspace, it doesn't make any difference whether that party is an LIR or not. That's sort of my general comment here. I know that research networks and universities having large amounts of old legacy address space is not the typical space, but if we want to go that direction, then we should come up with something which covers everyone sort of equally.
CHAIR: I know that this is always tricky to find wording that suits everybody. I would be happy if I could take this as volunteering from your side ?? don't talk to Rudiger ?? Wilfried. Can I take this as a volunteering from your side to work with us and with Philip on the text to get a version 4.0 that will sort of describe what we are aiming for without sort of putting undue burden on people in certain situations?
WILFRIED WOEBER: Yes. And the reason why I am sort of speaking up here is that we actually want to have something in place which is reasonable before we completely run out of the free pool. And I expect that in particular, for this region, we will not manage to get the ?? get a similar situation implemented with a service relationship, or a legal relationship between those legacy space holders, and the LIRs or the N CC as we did forth independent, whatever the term was, PI assignments. That's probably going to take another year or two maybe. So, this is stuff which goes ahead in parallel. If we would have that contractual relationship already, it would not be an issue to ponder that.
CHAIR: Thank you. I think we will take it to a small group of people to work on the document and then bring it back to the list and try to get it through quickly.
RUDIGER: I think the question, "What address space is covered by explicit current legal contracts ,"is kind of a distinct question to what's discussed here. However, I really have to say that dealing with the intent of the proposal is raising a lot of really difficult questions. How do you know which Professor 15 years ago at some of your universities got something directly from John Postell, and how are you going to ensure that this is taken into account when something happens? And well, okay, in large corporations, you do not know really whether some of the foreign subsidiaries did something or, well okay, even a small business unit somewhere next to the Headquarters.
CHAIR: It's going to be a tricky one.
Which brings us to the next one, which is also not that easy and straightforward as I would have expected. That's the initial certification policy for PA holders.
The basic idea was the RIPE NCC has built a very nice digital certification system to make sure everybody knows who belongs ?? who owns which address space. And they would just give certificates to ?? I am handing over to Nigel to get it all right. Basically the idea was the NCC would help us secure things and we overlooked concerns there, and the Working Group actually gave feedback that this is not what we want, which surprised us, and now it's Nigel to summarise.
NIGEL TITLEY: I am the person who has been set up to talk to you all about this particular policy proposal, 2008?08. It's had its first birthday. It's stuck in the driveway at the moment, and this presentation is an attempt to tell you exactly what's happened, and give you some ideas of how we maybe might be able to apply some jump start leads to it and get it going again.
Okay. What are the problems and what are the possible solutions?
What is it? It's a policy for signing allocated address blocks. It's PA only. It's RIPE NCC members only. And in its current form, it includes revocation of such certificates by the RIPE NCC under some circumstances such as closure of LIR, security breach, failure to pay your bills, all sorts of things like that. And if you really want to know the details, go and have a look at the policy. I am sure you can find it.
And in a sense, it's really only a small extension of the existing allocation policy in that it's just a means for the RIPE NCC to give a sense ?? a solid sense, an indication of who actually owns or has been allocated a particular address block.
So, what are the problems with it?
Well, we have got four sets of problems with it at the moment. There is contractual issues, which boils down to money. There are legal issues, which boil down to policemen. There are disputes which boil down to lawyers. And there is errors, which boil down to fat fingers in the end. I can't remember whether I have actually ?? let's go back.
Right. Contractual issues. Money. The thing that is causing problems amongst the community is that the RIPE NCC, in the original form of this policy, indicates that it would withdraw the certificate or allow a certificate to expire when the contract with the original allocated LIR comes to an end. Now, this is for very good reasons, because really the only means that the RIPE NCC has to indicate and maintain contact with an LIR is if they have a contract with them. And at the point at which that contract is broken, or disappears or goes up in smoke or whatever, the RIPE NCC can no longer guarantee that that PA space has, remains in the ownership of that particular LIR. So that's the contractual issues.
Legal issues. Policemen. Policemen have an idea that they can come along to the RIPE NCC, they can ask for a block to be removed from the database and that this will automatically switch off that particular bit of the Internet. The RIPE NCC says at the moment, yes, we can actually remove that address block from the database, but it isn't going to do you any good. Now, if lots start to be certified and if certification leads to secure routing, security BGP when it would give the ability for the RIPE NCC or any other issuing authority to switch off parts of the Internet. And a number of people see this as a problem. Okay. It's the big red button effect.
Now, note that you need both of those conditions to be true. You need certificates and you need secure routing. Okay. Certificates are coming probably. Secure routing is coming, but probably very slowly. So, we may have a big red button, but the big red button may not be attached to anything, whatever, okay. This may not be a problem. It depends on trust really.
Disputes. What happens if two people are claiming the same PA block? How do we sort that out? This boils down to lawyers and dispute procedures and things like that. We can probably sort that out.
Finally, errors. Everybody makes mistakes, even the RIPE NCC. And even our LIRs as well, and what do we do to back out of a problem where a certificate has been assigned to somebody it shouldn't have been or not assigned to somebody it should have been, or whatever?
So that's the problems.
Possible solutions. These are the jump start leads. Contractual issues. RIPE NCC could never revoke for contractual reasons. Okay. They could just let certificates expire, and the expiry time, the size of it could be reserved for future study. This group might well set that time. It could be six months, it could be six years, it could be 60 years. And also, there is no current revocation policy at all. And maybe we need to create one. And that might welcome from this group.
Legal issues. Only allow the owner to revoke is a possible solution to this one. Now, I am not a KPI expert. I am not sure this is possible. Steve Kent has valently offered to stand up after my presentation and give a couple of slides on whether he thinks this is possible and how we might do it. So, we are talking to the KPI people.
Solutions to disputes. A possible solution to this one is never issue a certificate if an object is currently under dispute. We have a dispute procedure. It's well documented, it seems to work, it doesn't get executed very often, but we may have this one covered off.
Solutions to errors. Well, the obvious solution to errors is don't make mistakes. Well, we try, we try...
If your process is right, then you are errors can be reduced quite a lot. This probably needs further study. Self revocation may help. If an LIR makes a mistake and they can revoke the certificate, fine, okay. Again, further study this group.
And that's it basically, questions. Not discussion, because we are not in the solution space, but if anyone wants clarification prior to Steve coming up...
CHAIR: Thanks for wrapping up where we are stuck in the process and why specifically, and now we have somebody who really understands this old crystal PKI stuff and tell us whether this is going to work or not.
STEPHEN KENT: So any questions so far? Okay, first admission: I am not an KPI expert. You can tell I am a PKI expert.
So I put together a few slides here, and at Rudiger's suggestion to talk about some options for local control with regard to the RPKI. First of all, this is the general model that we tend to talk about, for instance, in the SID Working Group in the ITF for how people locally will deal with RPKI. So there are a collection of repository out there operated by LIRs and RIRs. An individual relying party in an ISP who wants to gather this data and use it for improved security with routing, will go out to the repositories and chase down paths to collect signed, digitally signed objects, retrieve and validate these, these are certificates, CRLs, to get back to the point that Nigel was talking about on revocation, Roas, which are the way an address space holder identifies the origin AS for route originalation etc. Having retrieved and validated these, you have a global store of them that you maintain and then you run them through software to do processing relative to whatever kind of RPKI output you want. To getting RPSL objects to use with route filters or just getting prefix AS pairs that can be used directly in routers as we have been informed by Cisco and Juniper that we'll be able to do in the future, are the output stages.
Now, to put this in context, my company BBN is one of a couple of companies that's being funded to provide relying party software so the pink stuff from the previous slide, that somebody in ISP for instance, can run locally as open source code to be available, and in fact and initial version of it was posted on a website that APNIC runs, last year, and we are updating this.
And so part of this is soliciting inputs from you folks in terms what kinds of additional local controls in this sort of software you would consider valuable.
What can a local party do in terms of the RPKI? Well, in principle, you can do a lot of things. You can decide which entities are to be treated as trust anchors. And I won't talk about that today, but that was a presentation I gave at the CIDR Working Group meeting, a few months ago and you can certainly decide what to do with stale or expired objects, and I'll talk in the next slide about what the distinction between stale and expiration ?? staleness and expiration is. The real issue of course is what can you really do that's a function of what your software allows you to do? If we don't give you the control for it, then it's only in principle.
Certificates expire. They have a validity, not valid before and not valid after date, and normally relying party software considers an expired certificate to just be invalid. And so relative to the comments that Nigel was just making, if RIPE, for instance, adopts as a policy in the Certification Practice Statement for its certification authority, that it won't revoke certificates as a result of a contractual dispute, at the end of whatever period the certificate was issued forward, which presumably would be associated with the duration of the contractual agreement with some grace period, it would expire and the effect is more or less the same as having revoked it, in all honesty, that is it would not be considered valid any more. But you are a relying party. You can do anything you want if you have a control for it. So one possibility is to provide an override that says "I will accept certificates that have expired within some time window. I'll give them a grace period." You can do that, that's a small matter of programming. Now you get a lot of risk for having done that but you are doing it to yourself. You are not doing it to anybody else. A more local deation and so if people said wow, I'd feel so much better if I just had that capability. Tell me and we can put that capability in. That's something you could do.
Certificate revocation lists, in another kind of signed object we used in the RPKI called the Manifest, don't expire; they become stale. They have a next?issue date in them which is when you should find the new one and when that date is passed and you still don't have the new one, the old one isn't invalid. Everything it says is still true as of that point in time. You just don't have the latest one. It's stale. And you certainly can go ahead and deal with stale CRLs for instance, and that's very commonly done in relying party software anyway, to accept the fact that it's out of date. What you do is you POP up a warning message, the user ignores the warning message and you just go on. That's standard practice. So that's an easy thing to do.
In terms of the software that we have been producing, at the moment we allow you to deal with staleness not expiration, by saying you can require everything to be up to date, not stale, which is probably a setting you'll try once and then say okay, I didn't mean that. You can be warned about stale CRLs, you can be warned by stale manifests. You can just go ahead and accept them. So those are kinds of controls we already have in software that we have made available and presumably this will give people on a local basis lots of opportunities to deal with that.
We do require, as is typically the case today for relying party software, that all certificates be not expired. That's just standard processing. That's what the standards require. But if people said we really would like a let?me?shoot?myself?in?the?foot button with a knob that says what calibre or gauge weapon you'd like to use to shoot yourself in the foot, which would be the interval after which something expired in which you are still willing to accept it, we could probably go ahead and provide a control that did that.
Bad revocation. Which, I have been told is a serious concern. In any PKI, the certification authority that issues a certificate is empowered to revoke it. Period. That's the way PKIs work. No getting around that. Now, the circumstances under which it gets revoked are spelled out in the CPS for that CA. Sorry, I left that word off at the end. And so, since RIRs are member driven organisations, the first thing that you guys should be doing what is what Nigel was talking about, is as a policy coming up with the procedures that you consider acceptable for revocation. Period. Those should be stated and they should be ones that the members feel they can live with comfortably. It's your environment, your CA ultimately, and you should make sure that's something you want. The CPS would also typically describe technical procedures by which this is done. And so, for instance, if you are using a hardware security module which I think a CA of the scale and importance of RIPE should do, like other RIRs, you can require multi?party control so that no individual can sneak in in the middle of the night and do this. You can require, you can buy hardware that will do this, that will require, let's say, that shares of keys are held by five people and three of those people have to show up and insert little tokens into the box to sign something where in this case the thing being signed is not a certificate being issued, it's a CRL. That's a technical control. If that would make people feel more comfortable, make it part of the CPS and then the RIPE guys will go out and buy hardware that does that. That's a doable thing.
Nonetheless, relying parties still can have other options for dealing with concerns about inappropriate revocation. You can choose to locally override a CRL. It's a piece of information you have acquired from repositories, you validate a signature on it and if you really, really don't want to believe it, it's up to you. It's a purely local decision. But of course again that works only if you have software that you do that. So what might you be able to do? And Rudiger mentioned this to me on Monday around lunch time and so we chatted about it a little bit, and here is an example of an algorithm that one could implement in reliant software. The algorithm would apply to the certification authority certificates only. Not to CRLs that cover end entity certificates. The end entity certificates in the RPKI deal with things like individual row as manifest up. Presumably the concern is having an entire ISP or somebody with a chunk of PI space wiped out, turned off. So that's the set of CAs and therefore CRLs that you are really concerned about. So therefore let's limit it to that.
Secondly it only applies to non?empty CRL. If it's not empty, it's not revoking anything so don't need to spend time on that. It says when you encounter a CRL, if it has a new entry ?? "new" being relative to your history, because remember you are maintaining a local cash of the signed objects, you can require an operator to approve the CRL with a new entry before accepting it. Easily said I am not going to be the guy sitting there deciding whether to approve it. Once you approve it, it stays approved, so you don't keep being bothered by it until it changes again and finally, the change has to be adding a new entry. CRLs will have things time?out, that is when a certificate expires, the normal procedure is to remove it from the CRL and therefore CRL shouldn't just grow forever, they should grow and slink over time and the algorithm wouldn't require any operator intervention if things timed out and left the CRL. So it's only new things that are added because presumably that's the thread, if you will, that you are concerned about. If something has been revoked. You hadn't seen it revoked before and you concerned about it having been inappropriately revoked. So that would focus just on that.
Now, while it's easy to say this, there is a question of what's the operator going to see? Remember, a certificate revocation list is a list of serial numbers of certificates. So, just popping up a CRL and saying hey this is changed and here is a null revoked certificate. To first order what that shows you is a large number, which is probably not very meaningful. So, what you'd have to do is go back to your local cash to find the certificate that has been revoked. It's not going to be in the repository any more because it's been revoked. So it would have been killed out of the repository, which is a good reason for maintaining your own local copy of it, which is a smart way to run software. So he can fetch the certificate out of your local cash, pop that up and now what do you have? Well, remember in this PKI we have intentionally decided to not put in names which are human meaningful to avoid some legal liability problem. So you have a subject in an issuer name that doesn't do very much for you. The one thing that's in the certificate that you could display to an operator that they might be able to use meaningfully in terms of: Am I okay with this? Is the set of resources that are in the certificate that has been revoked, and these will be prefixes. So, that's what you could really tell somebody and say are you comfortable with this CRL entry which is now wiping out this set of prefixes in and if they are prefixes that are favourites of yours, sure, you can just say no to that and override it, whatever criteria you would use, you could choose to use, you could do that and could you automate that? Sure. You could imagine having a list of resources you consider to be important and you know, you could do things along these lines to help with the operator intervention but that's fundamentally where you would would be with this kind of capability.
So that's what we came up with in terms of a quick look at two things: One to remind people what kind of controls are already technically viable controls that are available in some software that exists today and which is continuing to be enhanced. And two: If there were a demand for things like a local CRL override capability, what's a first cut at what could be done to address that? And we are looking for feedback from folks in terms of: Is this something that if one went to the trouble of doing it, would anybody use it? Otherwise it's not really worth doing this software engineering.
So...
CHAIR: Thanks, Steve, for stepping up and explaining to us the options that we have in the technical framework fora dressing some of these concerns that have been issued. Thanks to Nigel for explaining again the concerns that people have voiced and giving us a background on this. I see a few people standing up on the microphone.
AUDIENCE SPEAKER: Bearing RPKI Dilitant. I am not an operator but I talk to them also. Feedback, immediate feedback that I have is one of the things that's missing in your straw man that you came up during lunch is, the case where you initially accepted and then realised it was a mistake. So you need that thing there also.
SPEAKER: Ability to accept it.
AUDIENCE SPEAKER: We say okay, we find out really we are not really accepting it. That's a minor detail.
Then I have a genuine question for understanding. Is there a channel in the CRL to actually give additional information about the reason for the revocation?
SPEAKER: Yes, there is a reason code field. My belief is that the current profile calls for not using it.
AUDIENCE SPEAKER: That's something you might want to consider and you might want to ask for feedback for meaningful classes of reasons, because that would probably help with the configuration. So what I am saying, just to be more transparent is that the RIR could say, we revoke this because of contract expiration. We revoke this because of legal action, a subpoena we got served with. We revoke this because we don't like the ??
SPEAKER: We never really liked them anyway.
AUDIENCE SPEAKER: So that would probably make the configuration easier. And you could specify the re ?? the relying party could specify a policy and say okay, we trust this class of reasons and we want this class of reasons we want to look at each individual one. And the last remark ?? I forgot. I sincerely and profusely apologise.
CHAIR: I think that was very valuable feedback with the reason and then having the policy set up to saying ignore all the legal stuff and never accept any of these revocations. Have the policy machinery at the disposal of the Receiver side.
SPEAKER: It's actually even technically possible to split the CRL by reason code. If we want to do that the standard already provides a means for do it, it's a question of is it better to do that versus just put the reason code in and let people sort through them. But if you would go ahead, Daniel, and send me an e?mail summarising that plus the other one you are trying to remember, I'd appreciate it and we'll take that into consideration.
CHAIR: I think it would be important to have the policy ?? how the technical machinery implements it under the hood is something I am personally not very concerned, as long as they have the policy nubs.
ANDRE: I think it's a very interesting presentation, thank you very much. But this is software implementation, so my question: How does those recommendations fit in the standard framework, let's say IETF framework, let's say you develop one application, I can go and develop another with different assumptions?
SPEAKER: I think I tried to sort of touch on that. It's typical for software to accept stale CRLs. And the bad news is that most software doesn't give you control over that. Software for processing RPKI stuff is custom software to begin with because of the 37?79 extension. It's not what comes with your browser. It's going to be software that people wrote specifically for this application.
Staleness controls are I think reasonable things to do, especially since we have additional things like manifests that can become stale. So, I don't think we are really stepping outside the boundaries in terms of offering these controls. They don't require any new format, you know no changes to format etc. It's purely local. So, from an RFC 72?80%, the algorithm there as the standard algorithm for cert validation allows you to put additional controls in and so we are not violating things. As chair of the PKX group, if I thought I was doing really bad things I wouldn't stand up here and say it. Rudiger wanted me to do something and I just told him, no, we wouldn't do that because that violated a whole bunch of things. What you get to do in the privacy of your own home as a relying party or your ISP for stuff locally you have a tremendous amount of flexibility in doing and it doesn't externalise the cost on anybody else.
So the only thing that we talked about today, when Daniel mentioned reason code, reason codes already there in the standard. I think we profiled it away in the document that Geoff Heuston wrote because we didn't want to add that complexity but as long as there is good use for it, we can go ahead and Geoff can do Revenue 17 of the document and add reason code back in that's already a supported thing. I think we are in pretty good shape here. A very fair question.
AUDIENCE SPEAKER: My question wasn't related to an assumption that you are violating some of the standards. It was rather I am concerned about my address space but what is happening with regards to revocation is about the relying party which I have no control over. So if we publish a best practices document, something within the standard practice work, that could be helpful.
AUDIENCE SPEAKER: Yes, but your point, I misunderstood the thrust of it. You are absolutely right. The one thing you have to remember here is that relying parties always get to make the final decisions. You can't force your desires upon anybody else in these environments. You are putting information out there that they can use or choose to ignore and we are talking about controls on what they can choose to ignore but it's always up to them, absolutely, I didn't say why when somebody says, you know, the police storm in and say I want you to revoke this certificate so it will turn off service. Your revoking a certificate doesn't turn off service. You have got thousands of ISPs around the world who have to choose to act on that new piece of data, they ultimately decide whether service exists or not.
AUDIENCE SPEAKER: That is the status quo that we want to perpetuate.
SPEAKER: There is nothing you can do to upset that because you are not all the ISPs in the world, even all the right members. It's ultimately up to them, they make the final decisions. We are talking about procedures to make people comfortable, policies to make people comfortable and technical measures in relying party software so you can locally make the decisions you want to make. Ultimately it's always up to the ISPs. Period.
CHAIR: Two more comments please and then we have to go.
AUDIENCE SPEAKER: Rudiger: I just wanted to kind of point the audience, which may have been stunned by the technical details to some extent, to ?? well okay, one of Steve's pointers that was saying, well, okay, it's up to the RIR membership to make sure that essential rules and policies get into this CPS document. That's really important. That's quite tiresome, but, well okay, I think that is very much an essential message, especially to a policy Working Group.
SPEAKER: Yes, I would say ?? and by the way Andre did a wonderful job of helping us clean out as much as as could reasonably be cleaned out of the CP, which is uniform for the entire RPKI, which gives each RIR each ISP acting as a CA a lot of flexibility in terms of policies. But the concrete way to go forward is to start writing the relevant sections of the CPS and put those up as individual policy items to be approved or you know, to modify them until they can be accepted. That's how you make progress, not talk about the general concerns, but put up specific text, have text with it to explain why it says what it says, and then modify it until people are comfortable. That would be my recommendation.
CHAIR: Last word.
DANIEL: I just remembered my last point. It's more a technical one. I had the slide up when you said, okay, now you present the CRL to the operator and what have you got? There is another suggestion I think that will come up is, that you might want to include an API or something where they can actually go back to their own tools that they have for looking at address space, and I would think about things like their local database so that they can display information that's reasonable in that context. Don't make it a closed piece of software but give this hook so that they could go to their own management system and say something, what do we know about this little piece of resource?
SPEAKER: Very good. Thank you for the suggestion. Okay.
CHAIR: Thank you. Let me then quickly wrap?up this.
We have heard about the concerns. We have seen some approaches that should help us go forward with the certificates without the risks that people are afraid of. I trust that the certification Working Group will go forward with the CPS document and with this policy proposal and keep us informed about when it's ready to be reviewed again and be discussed in the Working Group again. So for now, we have no action on the Working Group with this, but it's still with the certification taskforce, but we are informed that you are doing good work on this. Thank you for that.
My time schedule for this Working Group slot is completely messed up now, because when I put it together, I thought there would be up one slide from Nigel pointing to some other Working Group, and on Monday afternoon, we decided that we actually have something to present and discuss here and I think that this was so important that it was good to have here.
That means that the next point on the agenda, the global RIR return address space to ICANN or we don't, depending on what we like, thing, is something I am going to skip today. We will discuss it tomorrow. We have some spare time tomorrow, and I will just go to the run out fairly and the last /8 bits.
We have less time than planned for both, but we should at least be able to move a bit more forward.
This is the part that we are not going to do now. This is the part that we are going to do now. Why the original proposer and most of his co?proposers are here, as far as I can see. I have not asked them to come up on stage because it's not really necessary at this point in time.
The basic idea of Run?Out Fairly is to avoid that sort of in one of the last minutes of the remaining lifetime of the four address space, one big telco happens to be there with a huge request and the next big telco with a request of the same size just doesn't get anything any more because the first one grabbed everything. So the proposed idea to tackle this was to scale down the requests by reducing the the time period that they are meant to last for at some certain point in time. So, today, we are allocating for a twelve?month period, and this proposal is proposing to reduce this to nine months, six months, three months period at some certain dates. The exact details are in the next slide.
The Working Group, the mailing list so far liked this proposal. There have been some doubts on whether the time lines are useful. This is the proposed time lines. This is as of 1 July 2010, the NCC will reduce its twelve month evaluation period to nine months. The 1st January 2011, it will go down to six months. And in 1st July 2011, down to three months.
Nick Hilliard did some maths with the run?out rate and the end of the ICANN, IANA pool and depending on the exact numbers, who gets what /8 at what time, we might actually be at a point in July 2011 where the RIPE space is going to last for four months. Then we have a three?month evaluation period, which is not doing so good. So, I think Nick is suggesting to move the dates a little bit forward, but not change the structure of the document as such. Is Nick here? Do you want to comment on that?
NICK HILLIARD: Nick Hilliard. INEX. I am flattered that you call it maths. It was handwaving.
CHAIR: But it was very mathematical handwaving.
NICK HILLIARD: There is a genuine concern here because we are talking about a sort of a granularity of run?out rate of four months per /8 and I suspect we are not really going to know what's going to happen until significantly closer to the date and probably within the time line of the run?out fairly document itself. So, the issue then becomes: Can we model this in any sort of way which is accurate? And if we can't, does it actually matter really?
CHAIR: So what do you suggest we do with the document? Ditch it? Change the time lines? Change the approach?
NICK HILLIARD: I think it would be very useful to model this a little bit more rigorously. As I said, you know, what I did on the mailing list was very much a sort of a hand waiving process. And if we could get, you know, sort of maybe a little bit more rigour into sort of various scenarios, that might actually be useful. What I am very concerned about here is that, you know, that we would sort of take this hand waiving, you know, and assuming that somehow or another it is data. It's not data. It's hand waving. We need data and once we have our data we need to make a decision based on various feasible plans. So, would it be possible for, I don't know, the RIPE NCC, the various departments within there, to do various models?
CHAIR: I see Daniel standing at the microphone. I assume he has an answer for you.
DANIEL KARRENBERG: Daniel Karrenberg with his proposer's hat on. These dates were whosen not to ?? by the proposers, not to closely predict ?? sorry, let me start again.
The proposers consciously chose not to polish the silver bullet as far as the predictions are going and try to be very accurate. The intention was more to be in the right ball park and have easily rememberable and predictable dates so. Whole point from the proposers was we proposed those dates now, and people will note that it's going to be, what's going to happen when and it's not going to be last minute changes and things like that. That was the intention. And that's why it's 1st July, 1st January, 1st July, that sort you know, dates people can remember.
I think what ?? and I sympathise with Nick's point, because I also want to know in a scientific way, justify any proposals. But I think in this case, this is polishing the silver bullet, while the bullet is coming at you, and so I don't think so we should be doing that, and so this is good enough. I think it should move ahead. Predicting the future is easy. Being correct is the hard part.
CHAIR: Geoff?
AUDIENCE SPEAKER: Geoff Heuston: You don't know how hard. Of the 11,000 allocations in v4 that happened in the last twelve months or so, 12 /8 itses, 100, 100 individual allocations account for half of the address space. 1% of the applicants account for 50% of the space. Now, what if that 1% became 2%? You see, predictions rely on the law of very large numbers. That individual elaborations get swamped because most folk in very, very large numbers are incredibly predictable. But the problem I have got is that what we see right now is that the address space is running out because a very small number of extremely large folk are actually getting extremely large allocations. And if they happen to line up in the same month, and instead of 1% doing three /8s, 2 or 3 percent of these folk did their allocations, we'd be out within a year. On the other hand, if they back off a bit because of global financial crisis or whatever, you have got another year. This stuff, even though I have only got 26 /8s left, is incredibly uncertain, I am sorry, and the dates are so rubbery it's not funny. And I wish it were otherwise, but the industry is so bulked up that a very small number of folk actually have the keys to the run out in their hand. I don't know what they are planning to do.
DANIEL: Thank you for arguing for this ??
GEOFF: It wasn't in the context of proposer, neither for nor against, I was offering you an insight into the data itself.
NEILL O'REILLY: Neill O'Reilly, UCD with my co?proposer's hat on. I think Daniel has said most of what I was going to say and I like very much his idea of polishing the silver bullet because it sounds better than me, which is the better is the enemy of the good. But I think we have a clear choice here. We can decide there isn't enough rigour behind this proposal, we should go and do the analysis, or we can decide, we need a policy, it doesn't have to be perfect. We can always do the analysis again and if the analysis is finished soon enough, which from what Geoff is saying doesn't sound very likely, at least we'll have something in place. If it is finished soon enough, well, we can come with a better proposal in whatever, twelve months time. But I don't think we can afford to risk going ahead without something like this.
AUDIENCE SPEAKER: I like the idea, but with this schedule, you have to retrain people three times, even if you put it to them beforehand, they forget. So, you have to basically go three times to a change. Why not change it once. Change it to a sensible thing, and leave it that way?
CHAIR: What would a sensible thing be?
AUDIENCE SPEAKER: Why not using the middle, the six months at 1st July 2010?
DANIEL: Can I answer that? That was ?? the proposers at least considered that and we thought it was ?? would cause too much overhead and too much resistance. Of course if there is an overwhelming support for something like this from this community, we could do it. I don't think it's ?? it falls down because it causes too much resistance at the first step, and because it creates more tickets and more fragmentation.
The other hidden agenda here is actually having three dates where it's sort of a first come first served situation, that elimination has to be made, whether something, some request is in time actually gives the RIPE NCC registration folks three times to hone their procedures for the final one when really they have to make the determination which proposal was before the next. So, this whole sequencing and cut?off thing can be exercised three times which is probably good. But that's only a minor consideration.
CHAIR: Okay. I want to play this in a little bit different way than usual. There has been lots of support on the mailing list and a few people voicing their concerns and one of these people is standing on the microphone. So I am going to ask you directly, would you be happy with going forward with the explanation that Daniel and Neill gave?
AUDIENCE SPEAKER: I think very much so. The last question I asked was: Does this matter? And I think ultimately, given the arguments proposed by the proposers of the proposal, the answer is no, it doesn't matter, which we should definitely go ahead with the proposal as it stands.
CHAIR: Okay. So given that we really had big support on the mailing list, the last comment was from Wolfgang. Do you really think this is so bad that we need to rediscuss it or would you be acceptable to the reasons Daniel gave and we go forward?
AUDIENCE SPEAKER: Well, if RIPE NCC is happy with it, I am happy with it.
CHAIR: I am playing the ball to Filiz and Alex. Are you nodding? Are you scared? I see you are nodding. Filiz is sort of asleep. Alex has to implement it and he is nodding, so...
I think I will summarise the reasons why to the mailing list and then we go forward with this, and thank you for it.
Again, this took a bit longer than expected, but we still enter the last /8 discussion. Sander is going to summarise what has been said so far and the bulk of the discussion is going to take place tomorrow.
SPEAKER: We have been looking at what to do with the final /8 for some time now. I just want to give you a short summary of what has happened up until now, and look at how we can go forward with this. Because we are short on time I'll go through this quickly.
We have, at this point, we have two incompatible proposals: One from Philip Smith, and one from Alain ?? sorry, I forgot his last same from France Telecom. So I'll give a short summary of what those current proposals contain.
The first one says, okay, everybody gets one and only one allocation, a minimum allocation from the final /8. We reserve a /16 for unforeseen situations. Very simple one, but it is one?size?doesn't?fit?all approach.
The other one says, okay, you can only use it for migration to IPv6, follow the criteria as specified in RFC 5211, and everything is scaled down taking into account what you can do with NAT and stuff like that. So, and the minimum allocation sites will become a /27.
There was no consensus on either of these proposals. Some people thought one was better, some people thought the other was better. So, we decided to see on the mailing list which direction to go to. The first question I actually asked was: Do we want to put IPv6 related requirements in the policy? Are people who request IPv4 space required to implement IPv6 in a certain way? And the answer on the mailing list was very clear: No, we don't want to mix those two things. IPv4 requests and IPv6 requests should completely remain independent of each other.
So this went very nicely, so then I asked my second question. Do we want a fixed amount of address space for everybody who ?? do we want to use some downscaling? Do we want to limit the total amount of address space somebody can get in a year or a month or something? And there was not a complete hundred percent consensus on this one, but most people seemed to prefer the second option that there would be some down scaling of the request size.
So then we tried to see, okay, how should this work, how do you do down scaling? There are situations where you can use down scaling but there are situations where you can't, so how should this work? And basically, we couldn't get a clear answer on this one and more and more people started to say, okay, should we actually change the policies at all? We have policies, they worked for many years, so, all this changing things and changing requirements, is it a wise thing to do?
And then we started looking at the legal consequences. If we change our current policies, do we get into trouble? Will people say that we are not fair to everybody, or that we are blocking competition? And what would be the consequence of doing something or doing nothing? So, you know, what can we actually do within the regulations in the EU and other RIPE region countries?
So now I want to give the microphone to Axel, because the NCC did some research and looked at the possible consequences.
AXEL PAWLIK: We didn't do any research, we paid lawyers that worked, I think. Basically they say, don't panic. This is the situation, they understood the situation, they described it it was still intact so that's a good sign.
Basically they say any person, only the new ones, the old ones as well, should adopt procedures. Anybody can participate. It's not a closed club, we should not intend towards strict competition and we apparently don't do that, that's good and there should be as non?discriminatory as possible. There we need to distinguish, because of technical reasons, are the real live run out of IPv4 between new comers, new entries and old ISPs, they don't see a problem with that. Because there is a hard technical reason for that. So that's good.
It's on the slide. You can look at it. And the long 16?page text has been sent to the Working Group as well. So I think maybe between that was sent yesterday afternoon and this morning, you probably have read it in the evening. If not, again, there is low risk for all the proposed policies so far. They have been, again they have been adopted through ?? they would be adopted through the open procedures and open policy development process. They are not aimed to restrict competition and they are not discriminatory. That basically is good.
It was relatively easy to read even though the piece of text there, basically they acknowledge that shortage, before shortage is a real thing out there. It's a real technical scarcity, so this to some degree is justified. The proposals are there to include as many LIRs, as many operators as possible to promote technical prowess, that's good. There is still of course, there is strange people out there and they might still try to get at us. They would probably try to get at the RIPE NCC for operating those, on those policies, but it's very unlikely that they would succeed. Even if they would succeed with a complaint, then what sanctions and the worst thing that could happen is that we would have to change the policy. But then we are run out for good and I think that's not a big problem.
Thank you. That's it.
SANDER: Thank you for the overview. So, basically, with everything we have been doing up until now, we are doing fine. We won't get into any trouble. I actually expected some, some things with the new entrants, but even that was no problem.
More and more agreement on the mailing list, turned up that maybe we shouldn't be creating a whole new policy for the final /8. But not doing anything at all might also not be a good solution. So, because Remco has done some difficult policies in the past, I asked him to help us with this one, and look at the possible ways to do this, not changing all the policies, but just making some adjustments to make sure we run out nicely.
So, he came with some small changes to the policies and I am giving the microphone to him now. And let's see if this is something we can get consensus on, because it's clear that the two existing proposals won't get complete consensus, so, let's try this way.
SPEAKER: (Remco): The point is that you see it. This is a rough draft, a rough draft. I really mean a rough draft. The entire process of me being asked to come up with an idea started yesterday afternoon at about four o'clock. So this is really the really, really early version.
I thought this picture was sort of appropriate, setting the scene, the sky is falling. You could take the alarmist approach and say it's all over. You could take the more rational approach and say perhaps it's range.
So briefly going through all the arguments for the final /8 proposals. The first argument, we need to do something, because doing nothing looks bad. And it might not ?? and keeping things the way they are might not end up in a favourable position. Don't do anything. Why change stuff that has worked for years? Changing anything this late in the game might open us up to liability claims. Previous policy wasn't good enough for you? I don't know. Or just let's get it over it. Let's just let it run out. Let everybody bleed to death and see what happens. Think of the children. Will my grandchildren be able to use IPv4? How about human rights? How about the billions of people that are not on the Internet yet? How will they be able to get IPv4? Why would they care?
So, in typical Dutch tradition, we have invented the model ?? let's do a bit of everything. We have got to save something for a vyingly defined goal. We have got to change policy but make it fit in with current policy as much as we can. When are we going to do that? As soon as the RIPE NCC receive its final /8. So everything I am going to say from now applies to that final /8 plus whatever we have got on the shelf when we get that /8. Rule number 1 is save some for the vaguely defined future goal. With the /10 aside. That's 8,192 /24s, roughly reflects the number of allowers we'll probably have at that time. We are probably going to tie it to new network and post run?out period. So people deploying IPv6 networks which need to interact with IPv4, something like that will keep that outside of the policy for now. We'll just carve out that piece and think of what proper goal for that piece later.
Rule number 2: Pretty similar to the Run?Out Fairly, done in a different way. For each allocation request, if accept, only a single block of space will be allocated. And that's which best matches that request. So, if you do a request for a new allocation and it's been approved and it was for, I don't know, a /17, but the biggest one left in the cupboard is a /19, you are going to get the /19 and that's the end of it. Good luck. This is pretty much ?? this essentially has the same effect of what has in the Run?Out Fairly proposal, except there is no dates in there. It's pretty much a self?tuning system. This becomes part of article 5.0 of IPv4 allocation policy.
And the final rule: For additional allocations, 95% of all the address space is currently allocated to the LIR is used in valid assignments or suballocations. So we currently crank up the limit which makes it harder for people to go back and get more space, and only peak it possible for them to get more space if they can really justify using whatever they have extremely efficiently.
So, with that, I'd like to see some comments. Please keep it constructive. I will try to file the policy proposal shortly, and what do you think?
CHAIR: Sander: Thank you Remco for trying to help on a very short notice.
Well, what does the room think? We have two proposals. Neither of them seemed to get consensus. So now we look at something much more simpler, just tuned the current rules a bit. What do you think?
RAJOUL: RAJOUL from LACNIC. One question Remco: You say that if somebody asks for a /17 and it is approved, but the largest available block is 17, that they would receive a / ?? sorry, 19, this means that happen this is the largest continuous available block?
REMCO: That's right. So you are only getting a single prefix.
AUDIENCE SPEAKER: Okay. Thank you.
ROB BLOKZIJI: Rob Blokziji. I like this idea of setting, what was it, a /10 aside in one of your earlier slides in some fuzzy future use, I think you already gave a much less /TPUTey potential use. The RIPE NCC grows on an annual basis with between 500 and 1000 new members, that is new ISPs are starting as an Internet service provider. I don't think that this will stop when IPv4 runs out. People will start new businesses. And they have a few choices on how to do this new business: Either they acquire either v4 after run?out of ill?defined, grey, black or transfer markets, or invest in ever more complicated NAT based heaps of spaghetti, or they goer for a clean IPv6 new business, but need a little bit of IPv4 space in order to connect to the existing IPv4 part of the Internet. And I think it is reasonable and important, also from a political point of view, one day governments will wake up and say, oh at the end game you made a fundamental mistake and now you are restricting the growth of the Internet, and they would have a valid argument. Especially given the fact that we, with a very simple technical measure, we can avoid these discussions without hurting the existing Internet, and I find all this end game proposals highly amusing, because at the end, it's all gone and this is fine tuning in the last few minutes and I think it is very important to keep the fine?tuning to the absolute minimum because whatever you do, we will run out. And the more complications you build in in the last twelve months, the more liabilities you have got.
CHAIR: So if I understand you correctly, rule number 1, reserve some address space for future new entrants, you like that?
ROB BLOKZIJI: Yes.
CHAIR: Rules 2 and 3, do you think they are necessary or shall we just focus on rule 1?
ROB BLOKZIJI: No, you can do both, but I personally think rule 1 is the most important one here. Rule 2, there is a general feeling ?? we have never done this before. So there is a general feeling that maybe we should do something, and I think what Remco proposes is a very soft, simple proposal that hurts everybody equally, and that's all right.
CHAIR: Thank you. Marco?
MARCO: Yeah, well one point I am just thinking about like let's get it out of the way, you know, run out of v4 and get it over it, but it's not being constructive.
Rule number 1 is good. It definitely should be there. You never know what the future is going to be like, so saving a couple of bits for whatever will come at might be a good thing. I am not sure if it's rule number 2 or 3 you get the largest consecutive block. Now, here I see a small glitch, might not be true, but actually there is a key here for the host masters because let's assume how to repair a broken table, you cut it in half and you find the half which is broken. So, when we receive the first /8, the first one will be in the middle of that /8 so immediately we only can do /9s and if the Hostmaster actually assigns gradually, then in no time at all, the largest consecutive block will be like 24 and 23 you can actually damage the number in that way. If that's desirable effect, I don't know. But it is in there somewhere.
Remco: I fully accept your point. I think that if you look at all the RIPE labs website has some fantastic videos on how blocks are being allocated right now. There is some method to the madness, I'd have to look to Alex on an explanation on how it actually works. I think that generally the smart thing is being done so no /24, only /8s to begin with. This is all based on the idea that handing out blocks it done in a sensible way. If Alex wants to comment, please come forward and say your thing.
Alex: We can of course use any kind of allocation strategy that we want, or that you want. The one you propose is definitely one we can implement. It is not what we do now. What we do now with new /8s, we tend to make larger allocations from those first and as the available space in a /8 shrinks, we tend to make smaller allocations out of what's available there.
AUDIENCE SPEAKER: I didn't say you were inefficient. I like to know that if he we tell you you are inefficient, all of a sudden we are giving out very small blocks.
ALEX: We can do that if you want.
JOHN SCHNIZLEIN: John Schnizlein. With rule 2, assuming, and I am glad that that question was asked first ?? assuming that we do not change the mechanism for carving up space, it seems to me that your rule 2 would lead to the abruptness that Daniel's Run?Out Fairly seeks to avoid. Is that true?
REMCO: No, I think essentially it amounts to the same but it doesn't require us to set dates. Why is that? Because if people want a /17 for a period of a year, then it stands to reason that they will probably need a /17 every three months.
JOHN SCHNIZLEIN: Okay. But if the periods of forecasting are not changed, then ?? and I realise that's actually not a policy proposal in this region, but it is elsewhere ?? the general rule here says that if there is a big block left and the luck of the draw is that a big network has reached the threshold and goes and asks for it, then a large fraction of what's available, sort of rounding errors, would go away. Isn't that exactly the kind of abruptness that Daniel's proposal is designed to avoid and do you have a position on whether that abrubtness is necessary to avoid?
REMCO: I see your point but I don't think that in the end the consequences of taking a shorter interval or getting a smaller block as a result of a request are that much different in the end.
AUDIENCE SPEAKER: Just a short remark. I want to remind you that whatever policy we adopt, there will be a point in time that one member will get the last block.
REMCO: Absolutely. And I am not here to stand up and try to prevent that. This is all the final /8 proposals are kind of way to decelerate before we crash into the wall, but we are going to crash into the wall.
FILIZ YILMAZ: Filiz Yilmaz, RIPE NCC. I think I have a slight confusion about the rule 2. And I am thinking, okay, this is basically not changing the policy because the normal practice is already single allocation, you know, that we can give out. It's a a block. However, what you are trying to do, I think, is to avoid people coming back for more in bits and bobs each time but tell him like, this is the biggest that we have and you can only get the biggest that RIPE NCC can delegate. However, I think there is a bit of situation there where you leave the judgement of the delegation, how you do the address management on RIPE NCC's hands and depending on how we do the address management, the size of the block may change is one thing. The other thing is how you are going to award people coming the next day, and how are we going to tell them ?? oh you just got an allocation yesterday and you are coming for the leftover /19 today and you can't have it. According to the current situation, we can't say that. That needs a bit of working.
CHAIR: I think that's all quite easy because you gave them a block, they have to document that it's full to 95% and if it was assigned yesterday, they will have a hard time arguing that it is already full. Some of them will argue that they have just connected to 20,000 DSL users, but ??
REMCO: Actually, the only goal I have with this is that if people have a reasonable request for a /9 or whatever kind of lunatic size block, it will clean out all of the smaller blocks in the same go. So, in fulfilling a request, we basically ?? well, turn over the cupboard and see whatever we have got left and scratch it out together and see if we can match the request.
AUDIENCE SPEAKER: Filiz's comment was actually completely right in this situation someone comes for a /17 which presumably means they have assignments to make. Let's say they are a DSL or a cable provider, which is at the moment where the bulk of the address space is going, means they have deployment plan, assignments to make, they have a big assignment to make. There is no /17 available. They'll get a /19, which would be smaller than the assignments they are going to make. So the next day they register the assignments. And their /19 is fully assigned, which is the definition of used in the current policy. So Filiz is right, if something like this is accepted and the intention is still not to allow any one big request to clean out all the available address blocks, there needs to be some way of limiting this, and whether you ?? which way you do that, there is lots of different ways you could.
REMCO: I think you have got a very fair point there. At the same time, I don't see how any other way of doing this is not going to limit people, that what they can to, I think the one thing that we should be aiming for as a community is to at least see to that, whatever we have got left in the cupboard is going to be used efficiently. And if somebody actually is using those 20,000 or 30,000 IP addresses in their network, I mean, that's fair. I mean, it's too bad for other people, but the run?out period is probably going to be short anyway. I mean, I am not ?? we'll probably have some left over 24s, but I think most of it will be gone inside of three months.
SANDER: It's going to hurt anyway, so let's not try to fine tune this too much.
STEVE PADJETT: Steve Padjett. So why is this not something that actually can line up with like the run?out fairly proposal? Why can we not just say, you know, predict your IP address usage say through July 2010 and you know, go through that? Why not something along those lines?
REMCO: Well, what I felt was one of the downsides of the shortening, the time lines, which is in the Run?Out Fairly proposal, is it requires to set more or less arbitrary dates for doing this.
STEVE PADJETT: But if we proposed it as pre?tickets up to a certain period as opposed to like three months or six months or nine months like that, then you wouldn't have a flood of people on you know the week before January 1 when it goes from six months to nine months or whatever, you would have a flood of people that week, if you could set up an end date as opposed to arbitrary dates.
REMCO: Thank you for that.
NEILL O'REILLY: Neill O'Reilly. I think that some reference to the run rate is going to be necessary to forestall the kind of situation that Alex suggested a minute ago. If people are able to come back tomorrow because they have assigned all the last allocation they got. Effectively they are concatenating allocations and obviously this ?? if that facility is available, it favours the larger players and smaller players or new entrants can risk being squeezed in ways that will be perceived to be unfair.
Now, whether keeping the reserved /10 is enough to mitigate that, I don't know. It's an observation. I don't have a solution. I think we need to look?? I think we need to look both at capacity and rate here. We need the two state variables rather than just one.
SANDER: My personal feeling on this is that would be too much fine?tuning and extending the run?out period. But ?? yeah... I know what you mean.
WILFRIED WOEBER: I really like this sort of self?regulating approach, like the more we run out sort of, the more difficult it gets. My first assumption would be that the host masters are doing a reasonable job. So that's sort of the first assumption. I don't see any need to sort of be too specific in the policy wording advising the RIPE NCC host masters to do A or B or C. I think we can rely on the fact this they are doing the right thing. We will probably ?? everyone will gain if we engage with them during the implementation phase, sort of to make sure that what they are doing is reasonable so achieve the goal, and regarding sort of this throttling effect that we would like to see, I already have two or three ideas how it would be very simple to enforce this throttling and one of those might even be that even if a party comes back five minutes after they got their /19 instead of /17, simply serialising all the requests in the queue one way or the other would make them to go to the end of the queue. So, this would be a very natural throttling effect and if there is nobody in the queue, just hypothetical case that nobody else wants the address spaces, let them go ahead and get the next bundle or whatever. I think there are pretty simple things to do to ensure that there is a throttling and this sort of spoke?wheel effect that we want to achieve, but I would propose to leave that to the implementation phase.
REMCO: Absolutely. Thank you Wilfried.
AUDIENCE SPEAKER: That was way more positive than what I was going to say. I was going to ask what rights the requester has after they are denied and ask that in a simple way, is if they have the ability to come back in the queue and if so, where?
I want to push back to something in an earlier segment which said that in the mailing list there was a request to keep v4 and IPv6 requirements completely separate and I am going to ask my question again: What rights does the requester have when they are denied? And why is ?? why are we having our head in the sand and not saying "Hint: Do IPv6." I know I am biased on the this point, but ?? and this is a ?? somebody has got their head in the sand by not stating the obvious during this period. You are going to the end of the end. Somebody will get the last request and you know, this is an obvious, yet hard, solution here. I just want to know where that's going in this process?
REMCO: Well, I think that by carving out a /10, I have zeroed out that will eventually turn that /10 into a policy that will be very tightly linked to IPv6 deployment.
AUDIENCE SPEAKER: Sorry, somebody said this earlier. This is inevitable. So why aren't you doing it now?
SPEAKER: : Very briefly, because I think that given the time line and the requirement to get consensus from the room, I think tying v4 and IPv6 allocation policy to each other is currently contentious at best in this room. So, let's leave that out of this policy proposal. Just make a carve out and get this, get at least the idea of what we're going to do with final the /8 over and done with. Then think about we have got this carve out, what can we do with it? You are not a big believer, I can see.
SANDER: Well, we have run more than 15 minutes into the lunch already I think. So, I'd like to wrap it up here and we'll continue tomorrow at two o'clock again in this room. Thank you.
(Applause)