You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
57 |
Working Group: |
Address Policy |
Status: |
Final |
Revision Number: |
1.0 |
Monday, 27 October 16:00-18:00
Tuesday, 28 October 09:00-10:30
Tuesday, 28 October 11:30-12:30
Wednesday, 29 October. 09:00-10:30
Chair: Gert Döring
Co-chair: Sander Steffann
Scribe: Ana Matic (RIPE NCC)
Jabber: Nathalie Trenaman (RIPE NCC)
Ingrid Wijte (RIPE NCC)
Agata Peszkowska (RIPE NCC)
AGENDA
A. Administrative Matters
There was a comment from Peter Koch regarding the minutes from RIPE 56. There were no other comments received and the minutes have been declared complete and approved.
Agenda Bashing: There were no changes to the agenda.
B. Overview Of Concluded Proposals
And, a short update from the NRO Number Council (NC) on the global status of this proposal.
Louie Lee as a representative from the NRO NC volunteered to give an update on the status of the proposal in other regions.
Andrew de la Haye (RIPE NCC) volunteered to give an update on the implementation part of the now accepted policy.
There were no questions.
C. Current Policy Topics - Filiz Yilmaz
There were no questions.
D. New Proposals Since RIPE 56
E. Discussion of Open Policy Proposals, Grouped by Topic - PI and special-case address space related
Ian Meikle could not make it to RIPE 57, so Niall O'Reilly (Co-chair of the RIPE ENUM Working Group) volunteered to present the proposal on his behalf.
Brett Carr, the original proposer of the proposal is participating remotely by Jabber, so he will be able to answer any questions.
Peter Koch (DENIC) commented that DENIC's customers might benefit from the proposal, as they also run ENUM Tier-1. According to him this is a useful proposal and he supports the spirit of it, but is not happy about the wording of the proposal. The wording should be improved to make sense from a technical perspective.
Gert stated that the version presented seems to be an updated version and asked whether Peter would go along with this version or whether he had additional comments/suggestions for it as well.
Peter explained that he is not happy with the wording as some of the rules that do apply to TLDs do not apply to ENUM.
Gert suggested the DNS related worries are sent in writing to the proposer and the mailing list, so that the proposal can be updated/adjusted accordingly.
Brett Carr (Nominet UK) commented (via jabber) that he tried to write the proposal by changing the original wording as little as possible.
Marco Hogewoning (XS4ALL) wanted to know how many organisations would apply to this definition and what would happen to the organisations that operate both ccTLD and ENUM. Would they apply for two anycasting blocks or would they get one block to share?
Brett replied that those who applied for the ccTLD and ENUM would apply for two separate blocks, as ENUM and ccTLD are separate policies.
Antoin Verschuren (SIDN) had a comment about Marco's remark. He stated that the policy as written now gives him the right to apply only for the one anycast cloud which is not redundant enough.
Gert commented that this is the case at the moment and this proposal is trying to change that.
Ondrej Sury (CZ.NIC) stated that they also support the proposal but are missing the IPv6 policy for ENUM in it.
Jim Reid (Telnic) had a question regarding the definition of the ENUM Tier-1 operator and what is meant by the organisation that has been delegated the responsibility of operating the name server. Does that space go to whoever is running the name server for that particular country or to the organisation responsible for the delegation? They then potentially have ability to choose their own anycast provider and route that space as a part of the existing anycast operation. Does the space go to those running the registry or those responsible for the delegation, as this is not necessary the same thing.
Brett answered that it would be a registry but he would not have a problem with that being the government-sponsored organisation.
Niall O'Reilly (UCD) stated that the statutory responsibility in Ireland lies with the Telecomm regulator. To move this policy forward, if we have consensus on the mailing list that this is the useful thing to do, we should move forward. If further policy development is needed to refine the definition of who is in charge that can be done as a refinement or as an additional policy.
Gert thanked all for the input and a clarification.
Mohsen Souissi (AFNIC) stated that he is in favour of ENUM being treated as equally as ccTDL and anycast and pointed out that if more than one block can be received for both ENUM and anycast, clear rules and criteria need to be defined on how to obtain them.
Gert suggested that the discussion about DNS for TLDs needs to be reopened as two people had comments on the situation when three or four TLDs are run. He said that this is a bit out of scope for ENUM discussion.
Gert concluded that the wording of the proposal needs to be worked on in order to clarify who is eligible to get the prefix.
Kurtis Erik Lindqvist (NETNOD) said that the anycasting policy for TLDs was created because the RIPE community thought that TLD operators constituted a critical part of the infrastructure and therefore were allowed a special status. They were supposed to get prefixes so that they could give the prefix to their service for anycasting.
ENUM might be roughly equivalently critical to TLD operators and the argument here seems to be that if they do not necessarily want to buy a service from the same operator or if they apply a different policy, they need a different prefix. But if it is the same operator, why would they need two prefixes?
He stated that this is a very poorly written policy as the attention is probably not to get two prefixes to launch the same service for the same operator.
Peter disagreed that the policy is badly written and stated that this is a straightforward extension of the policy applied to ccTLDs. He confirmed that existing anycast policy was written so that the assignment should go to the TLD, not to the technical operator. So, it goes to the TLD operator but not necessarily directly to the DNS name service provider so that the operator could choose whom to hand it to.
He continued that this spirit should be maintained when extending the policy here. There might be reasons to choose either a different operator or even to give the same operator different prefixes because of the regulatory or operational requirements. The anycast cloud could be set up differently for both the ENUM Tier-1 registry and the TLD registry or TLD zone in question. With the same prefix, the fade needs to be shared and a single service cannot be provided in a single location but both or all services would have to be provided in the same location.
Gert added that there might even be regulatory things that prohibit putting ENUM servers in places where you have DNS servers, so there are reasons why there might be two clouds.
Marco commented that if we move forward with ENUM and then decide on the number of prefixes, we are creating a temporary policy. He stated that first the whole area of work should be covered.
Jim stated that he is agreed with Peter and disagreed with Kurtis. He said that a little bit of finesse with wording would make this proposal perfectly fine. The main point is that the definition of ENUM Tier-1 operator needs to be clarified. Peter's points are valid. The ENUM stuff is critical infrastructure in some ways and different to ccTLD infrastructure because it could be bound by different contracts, different levels of service agreement and different duration of those contracts.
Niall pointed out that he had missed one thing on the slide when preparing for it. The policy as proposed does not offer more than a single dedicated /24. It may need to be more precise to whom that is offered. Jim's comments are sensible but it looks as if we want to make this a much better worded document, we risk creating confusion by using different language in this document from the language that we use in companion documents and that will, at some stage, suggest to people that there was a different intent. This proposal is simply to accommodate certain parts of the ENUM name servers, which are somehow recognised as being more or less equivalent in significance to the TLD name server clouds. He stated that we should not try to achieve a bigger policy step than that one in dealing with this document. If some terminology needs to be tied down a bit, that is fine, but we should not worry how many blocks it is. The policy text states a single block, so lets understand it as a single block. If some country cannot fit the architecture that they need to deliver the services that they require, let them come back and propose a new policy.
Brett commented that Niall has put it exactly as he would
have done.
Kurtis again expressed his worry as if ccTLD, TLD and ENUM Tier-1 operators can get one dedicated block, to whom is it going? He asked what happens if one operator fulfils both roles. Who is getting the prefix then and how many?
Niall commented that this is obviously for the mailing list.
Gert repeated that this needs more work and asked for cooperation with Brett on the mailing list in order to sort out the details. He said that he can see that there is support for the proposal.
Gert stated that as the 2007-01 proposal is concluded and there is now a contractual framework for End User assignments, we can now resume with this proposal.
Jordi Palet Martinez (Consulintel) said that he has already drafted a new version of this proposal and if there is a support in the room, he will send to the mailing list for more feedback.
The main question here for the audience would be whether we want to have the additional criteria for the IPv6 Provider Independent (PI) space or is what is proposed here enough?
Gert stated that when this was first presented there was no experience with IPv6 PI space in the other RIR regions. In the meantime, the four other RIRs have accepted an IPv6 PI policy and are handing out the space.
Although, he does not agree with all IPv6 PI stuff seen in the routing table, the routing table has not exploded which is quite important. There have been a couple of hundred of IPv6 PI blocks given out in the other regions. What needs to be agreed here is whether we want the IPv6 PI space in the RIPE region and if so what will be the rules?
Marco Hogewoning (XS4ALL) voiced his support for the proposal. He wanted to know how much space will be reserved for the PI assignment for future growth and how long the reservation will be held.
Gert commented that this is an implementation detail and that we first want to agree on the fundamentals.
Mohsen stated that he does not like PI IPv4 or IPv6 space, so has been waiting for the alternative in IPv6 shim-6, which is not yet there. So, companies which are dual-homed and which use IPv4 PI space to do that, cannot do the same thing with IPv6 in the RIPE region. So, to reply to the question asked, the need is there.
Martin Levy (Hurricane Electric US) stated that they operate an IPv6 PI network. He pointed out that at the moment there have been 223 /48 assignments made in the ARIN region, 53 in the APNIC region, 7 in the AfriNIC region, 8 in the LACNIC region and 1 in the RIPE region.
If you go with PI space as an operator of the network, you cannot tell where that announcement is coming from. There is no colouring inside the hardware that tells you which registry it comes from. Therefore, as an operator, he has to accept /48s. So, the operator's argument about this can be taken off the table. Also, he stated that everybody else has already done it, so RIPE should just go ahead with it as well.
Lorenzo Colitti (Google, US) stated that they don't need a /48 as they have a /32. He agreed with the Mohsen's comment that the important effect on the pace of the IPv6 deployment is caused by the absence of truly workable multi-homing solutions equivalent to those of IPv4, which means shim-6 but also load balancing and traffic engineering. When you go to any sort of business that requires Internet connectivity for critical applications they will ask why they should deploy IPv6 if they won't be able to keep the network up by connecting to two different providers. He continued that we should also consider the effects of the adoption as well.
Davis Kessens (Nokia Siemens Networks) pointed out that we are creating a fairness problem by allocating a PI space to a company of a certain size and that company is a way bigger than many of the companies that received a /32. He suggested to either give less address space to ISPs that are too small or that all companies should get a /32. By adopting this policy, we would create two classes of IP address users and they might have the same needs. The idea behind a /32 was that it is an amount which is enough for most companies to not come back for a long while. He stressed out that we should be careful not to depart from that principle.
Jordi Palet Martinez (Consulintel) replied that with the existing IPv6 policy this is not the case. Most of the organisations that may need more space can already request a standard PA if they are an LIR. This proposal sets a /48 as a minimum size but if somebody justifies the need for more, they get more. So, there are not two classes of entities and it was not the intention of this proposal to create them.
Gert commented that in the other regions bigger organisations got up to a /43, so the argument that large organisations need more space normally works. The RIPE NCC IPRAs can look at the procedures deployed in the other regions to determine up to which size to go.
Gert also pointed out that there is already a difference between ISPs and other companies. ISPs get a /32 allocation and are supposed to make /48 assignments out of it to the End Users. And a /48 by definition is supposed to be big enough for most End Users/companies.
This proposal will go to the mailing list for the feedback and we need to see whether we need to change the size back to a /32 as it was in the beginning. Also, we can see if the other regions had any issues with the regulators regarding this.
Mohsen said that there is an option to have a small, medium or a large company. He commented that the fairness problem is not really a valid argument, as if you are a big company you become an LIR and get a /32. Also, he suggested that we could see if there was any fairness issues in the other regions where the policy has already been implemented.
Gert said that the way to go forward is to take this discussion into account and draft the formal proposal then send it to the mailing list.
Jordi commented that he will send this informal proposal to the mailing list and at the same time start the formal RIPE Policy Development Procedure (PDP) with drafting the new version of the proposal with the Chairs.
Note: We are waiting for the IETF to pick up ULA-Central, which does not seem to be happening, so the Chairs suggest withdrawing this proposal
Jordi stated that the community was awaiting movement from the IETF and there has not been any movement there for the last 18 months, so he suggested that this proposal be withdrawn. If some movement with IETF happens, this can be proposed later at some point.
Gert clarified that this is about the separate proposal, which suggested that the RIPE NCC should set up a registry for ULA with the central registry. The action from IETF is needed in order to go forward, which has not happened yet, so this proposal will be withdrawn.
Gert clarified that this proposal was waiting for the 2007-01 to be completed and so discussion should resume now. As the author of the proposal was not present, he presented it himself and asked for the input.
Kurtis stated that RIPE NCC has never guaranteed the routability for anyone. He said that he does not think that this is a good idea and does not see what problem this proposal would solve. He said that there was already a discussion on this two years ago when Leo Vegoda, then working at RIPE NCC, was asked to produce data on how many requests like this the RIPE NCC got and it was a very few.
Gert explained that people who want to be honest about their needs cannot get a /24 without having to lie.
Kurtis stated that it is an unreasonable burden for the RIPE NCC to make this judgement. He questioned whether this would be applied retroactively as well.
Gert pointed out again that there was a two-year delay on this proposal as it was waiting for the 2007-01 proposal to complete the PDP. So, this proposal is two years old.
Rüdiger Volk (Deutsche Telekom) asked what lifetime does this particular proposal have. He pointed out that fixing a boundary in the policy like this looks like a misguided thing. He suggested this proposal is dropped, as things will be changing on a much larger scale soon anyway.
Marco commented that if this proposal is pushed forward, it should be made sure that all /24s come from a very well known block, so the filters can be adjusted to /22 and only the /24s from a specific block allowed. He disagreed with the proposal.
Janos Zsako (3C Kft) also voiced his disagreement with the proposal. He stated that it would not achieve what it is intended for. The RIPE NCC cannot guarantee routability by assigning a /24.
Gert concluded that there was not much support for the proposal. He asked if there was anyone who really wants to go forward with this. Otherwise we will send an email to the proposer to withdraw it or rewrite the proposal.
Gert reminded the WG that the RIPE NCC is conducting its membership survey and he asked for participation.
Welcome back, and continuation of the "PI and special-case" topics
Randy Bush asked what happens for other meetings that need IPv6 space and about the routability of a/48?
Andrei replied that the RIPE Meeting is not special. He pointed out that the IETF has a dedicated /32 which they received from APNIC. There is a provision in the APNIC policy that allows LIRs to receive an assignment from APNIC on the condition that they operate in the Asia Pacific region. However, the RIPE NCC probably won't operate in that region in the foreseeable future.
Randy Bush commented that maybe there should be more general approach, which would include other meetings in the region as well. He suggested that the RIPE NCC could look at APNIC's policy. If the RIPE NCC has a problem, other people will have problem too.
Andrei replied that if there are other specific cases, this proposal could be extended. He pointed out that this proposal was seen more like a way to document this specific assignment.
Rob Blokzijl (RIPE Chair) asked for the answer regarding the routability of /48.
Andrei answered that there are lots of people interested in the routability of this particular /48, so this problem should be solved. He pointed out that a /48 would be enough, but if the RIPE community agrees with /32 that would be even better.
Rob commented that there were two issues here: the practical problem for RIPE meetings and the one that we might not be the only ones with such a requirement. He suggested that we could solve both things by thinking about more general policy.
Cathy Aronson (ARIN Advisory Council) asked whether this is not a more specific case of IPv6 PI policy.
Andrei explained that in the RIPE region there is no IPv6 PI policy yet.
Cathy suggested that the people against the PI proposal would probably be against this one as well then.
Gert asked whether having an IPv6 PI policy would do for RIPE Meetings or whether there is a benefit to have a special “earmarked” prefix.
Andrei replied in principle the PI policy could be used for this but having a contractual relationship requirement might complicate the set-up. It would mean that the RIPE NCC would have to pay something, make a contract with some of the LIRs, which would make a contract back to the RIPE NCC.
Cathy asked if the more generalised PI policy is not allowing direct assignments from the RIPE NCC to the LIRs.
Gert explained the details of 2007-01 and the two options, which would be to either have a contract with an LIR that the PI is going through, or if you don't like any of the LIRs in your region, you can have a direct contract with the RIPE NCC. The policy doesn't really take the RIPE NCC into account.
Andrei commented that it would be a bit obscure if RIPE NCC makes a contract with itself.
Gert said that one option is also to find a company to do all the meeting stuff for RIPE NCC. Everybody agrees that it is useful to have a stable prefix, but the mechanics need to be decided.
Andrei commented that there is no formal proposal, but it can be made and put on the mailing list. From the feedback received, the way forward can be decided.
Rob commented that it would be overkill to go though the whole PDP process for one exceptional case. If a general policy for meeting organisers is developed, it would be a different matter. For the specific case of the RIPE NCC he suggested to find a simple technical solution and sort out the paperwork later.
Shane Kerr (Afilias) disagreed with Rob. He said that the RIPE NCC should go through the whole process of a policy change as everybody else has to.
Rob responded that a solution is needed before the next meeting, so we should go on with the more general policy that would also cover this specific case.
Andrei commented that more general policy might take much longer. He suggested to integrate a more general policy into this one later.
Gert concluded that this should go to the mailing list for more informal discussion to figure out which way to go and then decide how the proposal is going to be written and if the formal proposal is needed at all.
F. End of IPv4 Session (1)
Randy Bush (IIJ) commented that he is not disagreeing with what was shown, but asked whether there is a difference in having a blindfold on or off when driving into the brick wall.
Remco van Mook (Equinix Netherlands) said that he would prefer to have it off and see if hitting the brick wall could be avoided.
Randy stated that as we are running out of IPv4 and he also prefers to take the blindfold off, this is not a critical issue to argue.
Remco replied that this is the third RIPE Meeting where he is presenting essentially the same proposal and taking down objections one at the time hoping that it will convince the people that are self assured that there is no market currently, or otherwise.
Rob asked for a particular slide to be shown again. He commented that it is interesting to see that in this particular example, the transfer has been done in a complicated way in order to get the registry in order. So, apparently people still think it is useful to have an accurate registration database of the IPv4 space.
Remco replied that it is also in the buyers' and sellers' interest that there is an accurate database of assets, if you are going to call it assets because duplicating an IP address is extremely simple. You better know for sure that whatever you are buying is actually what somebody else owns right now.
Rob said that we don't have tools to allow/disallow and regulate or not regulate a market. We register the use of the address space. He recommended that the WG started to think about the registration policy and not so much transfer policy.
He stressed that in the long run the most crucial thing is to focus on the accuracy of the database.
Remco replied that the WG has been working on the transfer policy for a year and a half now because that is the maximum that we are going to get consensus on at this moment.
Daniel Karrenberg (RIPE NCC) thanked Remco for being persistent and taking one objection after the other away until finally achieving things. He also asked the question that if we assume that the process is about the commercial transaction, is it not likely that the commercial transaction will be agreed before the need to the RIR is demonstrated.
Remco said that in his reply to the renewed ETNO position on this proposal, which ETNO now says that they are now supporting, he has shortly described what he feels that that process should look like. He continued that what it basically comes down to is that people looking for address space can just fill in the form as they have always done and then instead of getting address space allocated by the RIPE NCC, which cannot happen because they do not have it, they get put on a pre-qualified list and that this list should probably be public. Then there will be a list that will eventually hold all of the active LIRs that are pre-qualified to acquire address space, which is an interesting list for people who are interesting in selling that address space.
Daniel commented that he is not sure whether it is realistic to get in front of the commercial process or whether we will be at the process slide where people will work around this and then the RIPE NCC will become an instrument and will lose its credibility.
Remco agreed that any hurdle is probably going to chase a few people away from the process. At the same time, there needs to be a process that everybody here agrees on. He concluded that there are two concerns here. One is that we keep our database accurate and the other one is that we don't have any competing databases springing to life.
Cathy commented that in the ARIN region they haven't thrown out demonstrated need in their proposal. She also had a question on the ideas of how to move forward and get consensus in this region that could also help them.
Remco stated that there is no way out of the market and that we are pretty close to the consensus in the RIPE region but that is something the working group chairs should comment on.
Max Tulyev (via Jabber) asked why would people decide to buy the space instead of asking for an allocation, which is still cheaper and possible now.
Remco replied that this question should go to people buying the space.
Leslie Daigle (Internet Society - ISOC) made a comment that even if the RIPE NCC or the other RIRs recognise that there isn't the possibility for them to regulate a market, it is important to keep in mind that somebody might. And while that certainly does not need to distract from these processes, she suggested to keep in mind that while focusing on keeping the registry information accurate and keeping the database accurate, you should also be careful how you line up with entities that might think they can regulate such a market.
Rob expressed his full support for this proposal. He recommended that it should be accepted and implemented it as soon as possible, and then further goals should be focused on.
Mark McFadden (BT) said that the changes made by Remco were very helpful and that he is supportive of this proposal as well.
End of IPv4 Session (2)
Gert asked for feedback.
Janos commented that this is an interesting proposal and asked whether there will be any restriction on a second request from an existing LIR after the exhaustion of the free pool.
Philip explained that they can only get one and cannot apply again after that.
Daniel asked what is the justification for the proposed allocation size, as it is for more members than we currently have.
Gert stated that there are about 5000 members at the moment.
Randy stated that he is a co-author of the proposal in the APNIC region. He explained that many people said the reason for the global five /8s proposal was that there could be a plan for the end. That is a reason why a last /8 was chosen in this proposal. The reason for that many pieces in the APNIC region was that those pieces are of the current minimal allocation size. Also, over the next ten years, there will be new entrants that will want to come in and they will need a little bit of IPv4 space. So that is why, even though there are only 5,000 members now, which with the current allocation size would use up less than a /8, more space is taken into account for the new entrants.
He explained that in the APNIC region a /22 is a minimum allocation right now. However, in two years, when we run out of IPv4 space, it might be a /27.
Daniel commented that from what was shown in the slide, this proposal would prevent one big ISP taking all the space from the last /8 and this is not a real intention of the proposal. What Randy just said is a real intention.
Gert added that it is actually two sides of the medal. It is intended to both, reserve some space for new entrants and also prevent one organisation from taking it. He concluded that there don't seem to be any major objections to the proposal so the proposal will go to the mailing list and the arguments will be more precisely described
Daniel commented that if worded like this, the proposal will get people to start de-registering legacy address space from the database in order to hide it. He said that de-registering legacy address space from the RIPE Database will not cause them to lose routing, so it will provide the incentives for making the data less accurate, which is of a concern as it is contrary to the goal of having an accurate registry. The legacy space is not controlled in any way, whoever is the maintainer can just delete the records.
He pointed out that it should be recognised that this is against that goal of having an accurate data and a decision needs to be made which goal is more important, accurate registry or this kind of conservation.
He added that there is a historic RIPE Database and routing registries and that these are operationally expensive. To counter this, we might decide to do further investigations and get the situation where the legacy space, although deleted, would still be counted because it was there once.
Gert added that this was a good point to take into consideration. He asked somebody from the RIPE NCC's Registration Services department to comment on how much we know about the early registrations. He added that he is not sure whether the RIPE NCC can actually pinpoint which organisation owns what or is there just an inetnum there, which is not necessarily tied to the same organisation.
Ingrid Wijte (RIPE NCC) stated that the RIPE NCC updated the objects for which they were contacted, so it is known who is using them. As for the big chunk that has not been updated since the Early Registration Transfer (ERX) Project, the RIPE NCC knows as much as everybody else.
Gert concluded that if we go further with this proposal, the implementation would not be that straightforward.
Shane agreed with Daniel's concerns but he pointed out that there are technological means that can be used to prevent deleting of the records. He pointed out that the main reason that this is a problem now is because it was not dealt with years ago. He suggested that it would be better to deal with this now than to have the same proposal coming up in three years time and then having a real problem.
Dave Wilson (HEAnet) asked whether an LIR needs to enforce this rule as well when making assignments to its own customers.
Philip explained this the proposal is only talking about the allocations.
Dave pointed out that then there is a loophole in the proposal. And if this is a part of the proposal, then he would be concerned that an LIR does not have means to reliably make consistent checks for every single customer.
Rob asked how much would be gained from this proposal. He said that given the fact that, in his opinion, there are other issues surrounding the legacy address space, which are much more important, he would be very reluctant to approach legacy address space holders.
He pointed out that he would be much more interested in approaching them with a more positive attitude. Considering that you are a prime target for address space hijacks in the near future, it would be useful to properly registry your legacy space. According to him, the community should not go in that direction, as not much would be gained from it.
Philip pointed out that this policy is intended for the LIRs who have address space that is hidden away somewhere and that they never got from the RIPE NCC. It was not the intention of the proposal to have the RIPE NCC go chasing after people that they haven't heard from for years.
Daniel agreed with Rob and repeated that we should not try to fix something which would gain us a couple of months at the most, but rather focus on the long term goals.
He also pointed out that although it was concluded that the accuracy of the legacy space in the database is quite grim, there is an effort on the RIPE NCC's side to improve that.
He stated that he is personally driving an effort in the RIPE NCC to assess the quality of the registration data, and to publish the results and do this retrospectively so we can see how the quality of our registration data has improved or deteriorated over the years. Significant resources are used to improve the situation of the legacy and ERX space.
Shane commented that this would be a false economy meaning that, according to him, both dealing with the legacy space and accurate database are possible. That is an expensive option but the cost of maintaining the IPv4 blocks are going to be increasingly higher and, hopefully one day in the future, higher than getting IPv6 set up on the network.
He stated that it does not really matter how much time is saved by bringing the legacy space into the pool; it is more a question of fairness, which is going to be important when people from outside the community look at the processes that go on here.
He continued that people who have never looked at them are going to start looking and they are not going to have the education and are not going to know how things came to be the way they are. They will start asking
questions why there are people with dozens of /16s when they cannot get a single block.
He pointed out that this legacy space needs to be brought in regardless of how much time it buys.
Rüdiger commented that the policies were designed with the idea that it is the applicant's responsibility to provide accurate information about the resources they are holding. He said that Daniel's particular concerns probably would not apply if one actually says that the assignment is valid if the represented information is true. If it turns out that someone is lying, it is an accepted practice in many places, the decisions will be revoked in some way.
Gert added that this might be a good way to move this proposal forward. He suggested the proposal is put back on to the mailing list and that what has been said here is taken into account and rewording of the proposal is
worked on.
ACTION (RIPE NCC): Look into the feasibility of the proposal, which can be done when the impact analysis on the proposal from the RIPE NCC is published.
G. Cross-WG Material
Nigel Titley (on behalf of the Certification Task Force) pointed out that although the proposal has his name as an author, it comes from the Certification Authority Task Force (CA-TF).
Joao Damas (ISC) asked why certificates would expire on a regular basis. Why would one suddenly have to renew something that did not need to be renewed before?
Nigel responded that it is generally regarded in security circles that certificates should regularly expire.
Rüdiger added that it is a basic feature of the PKI technology that is used that every certificate has a limited life span.
Randy rephrased Joao's words. He said that if the membership is maintained, the certificate is issued every year. So, what Joao was saying is that currently, even if the membership is not renewed, the address space is not revoked. By letting the certificate expire without issuing a new one, the address space is effectively being revoked, which is a major policy change.
Gert commented that the RIPE NCC is revoking address space, if LIRs refuse to pay their bills for long enough, they will be closed and the address space will be revoked. What we cannot do today is to stop it from being routed.
Robert Kisteleki (RIPE NCC) explained that there is a technical reason for doing this and that is when you revoke a certificate, the organisation is put on to the revocation list and if the certificates have practically infinite lifetime then the list practically grows infinitely. You can argue how long you want to make it but you shouldn't make it arbitrary long.
Joao said that he is not aware that anyone has had address space withdrawn because they cease to be members of RIPE NCC. They have had services suspended such as reverse mapping, another in-addr.arpa service, but not the address space itself.
Ingrid responded that over the last year Registration Services has been contacting the closed LIRs that still allocations and checking whether they were still using them. If not, these blocks were taken back. In the cases of the violation of the policies, blocks were also revoked.
Joao commented that that is conforming to policy. If there is no longer a demonstrated need for the address space it can be reclaimed. At no time has the LIR continued membership. And these are two different things.
Remco stated that it's a very bad idea to limit what you can do in the policy to whatever implementation you have chosen in technology. He said that certificates by themselves are a good idea but choosing a certificate with a limited lifetime for technical reasons is a bad idea.
Gert asked for suggestions.
Remco replied that technology without a limitation should be chosen.
Nigel stated that there is no any particular reason why certificate life times should not be extended. Certificates can still be revoked when the contractual relationship ends. He asked for somebody from the CA-TF to comment on that and added that 18 months was a fairly arbitrary decision.
Rüdiger said that the initial proposal was for a minimum of 18 months. Turning the minimum into maximum would be a significant change. The idea of using a short life span is expecting that revocations would have to be done fairly often and dealing with revocation lists is painful and is the down side of PKIs.
Gert asked what happens if an LIR stops paying bills but is still using the address space.
Ingrid explained that Registration Services will contact them but that there is no mandate to take it back.
Gert concluded that Randy was right, as this would be a significant change to the existing policy. He abstained on saying whether he thinks that is good thing or not because that was not his role. The community needs to decide on this.
Randy pointed out two things. One was that this little bit effectively moved revocation of address space from revocation policy, which is worth discussing and doing, to the certification policy, which as already pointed out, is dangerous. The second point is that this is going to discourage people from playing in the certificate game, which is extremely important in the long run for routing security. This change from a certificate to revocation policy might make people feel uncomfortable with certificates as they might start thinking that if they start using certificates, the RIR will control their routing. This becomes address space revocation and therefore the policy of expiration times and not a certificate policy.
Gert concluded that one possible approach would be to reword the certification policy proposal in a way that says as long as the address space is assigned, the RIPE NCC will continue to renew the certificate on a regularly basis. Whatever lifetime is practical can be used. And at the same time, an effort to define the revocation policy needs to be made, which would be a different policy document
Robert said that the certificates are not there to introduce any new process in terms of assignment and revocation of address space. Certificates are there to provide a more secure means of being able to prove that you are the legitimate holder of any address space. Revocation of the certificates and issuing of the certificates are going to be tied with the actual fact of holding some address space.
He also explained that the reason for picking 18 months was that it is expected that when an LIR pays its annual fee, then they will receive the next certificate mid-next year or so, so that is roughly 18 months, but this could be shorter, it could be longer.
The basic idea that was pointed out by Randy as well is that we will give out the certificate as long as the LIR holds the resource or the End User holds the resource, if that is going to happen.
Nigel added that the proposal needed to be reworded.
Max (via Jabber) wanted to know who will decide that the contractual relationship should be stopped and the IPv4 network revoked and how. Will the core decision be mandatory or not? He suggested that there will be a lot of cases where the RIPE NCC will close the contracts and get back the resources but the End User will disagree with the decision. He wanted to know how this situation can be solved.
Gert commented that normally there is a contract that says that if you pay the money, the contract goes on and if you stop paying the money, the contract expires.
Randy added that the contracts have been separated from the certificates.
Dave agreed to what had been said. He stated that it is already the case that if there is a change in the address status in the RIPE Database, this has an impact on the routing. He said that if his addresses disappear from the RIPE Database tomorrow then the following morning some of the peers and up streams would no longer accept announcements.
Rüdiger agreed with Randy's statement.
Leo Vegoda (ICANN- via Jabber) asked if the certificate can be renewed without having a current business relationship with the RIPE NCC and how could the RIPE NCC use it.
Daniel answered that if there is no legal relationship between a certificate holder and an RIR, we will not know who the certificate holder is. If we issue certificates with a very long lifetime, and only the possession of the private key will be used for anything consequential in routing, trading, the consequence will be that we will lose the registration. He pointed out that a way needs to be found to do this and to take away the fear at the same time.
Randy said that the RIPE NCC might reissue certificates to somebody who is not responding, which is a problem of identification, and keeping data current but that this problem should not be solved by making people fear the routing system.
He pointed out that there is a new draft, cooperatively by CISCO and Juniper, in the CIDR Working Group on using the RPKI for how it will be used to validate an origin.
Gert commented that a certificate is not issued by somebody. It is a private key that is sent to a person. If that person is no longer known, this can be awkward.
Randy said that when the contract is still there, the RIPE NCC cannot use the certificate.
Gert concluded that a revocation policy is needed because we do not have formal decision what we are going to do with those LIRs that are acting badly. At the same time, we want this proposal to go forward with changes. The way forward would be to incorporate the spirit of what has been said and bring it back to the mailing list.
Filiz Yilmaz (RIPE NCC) clarified that there is a section which is called "Closing an LIR" in the current document and it outlines when such a thing can happen. The last sentence is "the RIPE NCC takes on responsibility for address space held by closing LIRs." She suggested that that is possibly a related bit for the future revocation policy.
Gert stated that he would welcome a volunteer to draft a somewhat more detailed revocation policy.
Robert (speaking for himself) pointed out that since certificates are there to represent what is true, maybe the RIPE NCC should not mention how this is done but only give out certificates for real holders of the resources.
How the RIPE NCC does it is a procedural question and maybe it shouldn't go into the policy.
Nigel concluded that there is enough information to redraft the policy and resubmit it.
Randy concluded that this is a real progress.
Followed by time for discussion (touching DB WG and routing WG)
Gert explained that as the proposer was not present, he would present this proposal.
Remco said that he is in favour of changing the text as it is proposed in this proposal but he commented that any discussion on the merits between ASDOT and ASPLAIN should be at the IETF and not at this meeting.
Randy agreed with Remco and added that he did not want discuss AS DOT. He pointed out that a similar policy had passed in APNIC. He said that APNIC is sitting on that policy because they did not make the mistake of putting either notation in their policies, so they do not need to push it through. If the RFC comes out before the end of the year, this policy will be put aside; if it does not, because four byte AS numbers have to be issued by 1 January the policy needs to be in place. But moving forward here to correct the text is something that needs to be done.
Rüdiger said that some of these things look like protocols and that they should not be decided on by policy actions. It needs to be made clear what protocols we are talking about.
Gert said that this was input for the Routing WG.
Dave said that he will be talking briefly at the Routing Working Group about this. There is an existing software deployed quite extensively that breaks in exciting and unpredictable ways on AS DOT and we should make this change.
Gert added that this discussion should not be started in this WG.
Andrei said that 1 January, 2009 is probably not a milestone in regards to this particular proposal because the RIPE NCC has been allocating 32-bit AS numbers with existing notation for two years now.
Gert said this is actually affecting existing registrations in the database as well, so the working group chairs have discussed this and the Database WG is aware that something will be ending up on their plate as well. He said that the question is who decides on how AS Numbers get written and whether it is decimals, dots, colons or whatever else. The IETF might be the right body to specify this as they are the technical standard body and this is a notation for technical things, it is not protocol per se but it is a protocol element.
Andrei responded that he was not questioning the proposal but stating from the implementation point of view that 1 January is not a milestone for the RIPE NCC.
Marco said that this should not be a proposal: it is merely a formative change and does not touch the policy as such on how to design it.
Gert responded that, as it is today, it cannot be just changed. For upcoming policy changes, there is stuff to learn from this and we will try to avoid writing things in a way that if a standard body decides that notation changes, it will affect us. All the other policies do not specifically mention how things are written.
Marco replied that he did not think that in the future it could be avoided by being dependent on standards somewhere in a policy document. He suggested that maybe we should discuss the Policy Development Process as well to see whether or not formatting the changes are a change in policy.
Gert said that formatting will be on the agenda for the next day, so this is taken into account.
Rüdiger commented that this is of relevance for the Database WG as it is a change of the RPSL being used. If the RPSL protocol is being changed, this should be done in a way that injects fewer problems for the clients using the database than it has been done for the initial introduction of the extension.
Gert replied that this is important input for the Database Working Group to think about and come up with an implementation plan that will give people advance warning and will not make all the software explode.
Denis Walker (RIPE NCC) said that the implementation is of relevance for the Database Working Group. He pointed out that the bit that is relevant for this working group is what is going to happen on 1 January.
Two years ago the agreement was that all RIRs would start issuing 4-byte AS numbers by default on 1 January, 2009. When Filiz was talking about policy proposals, he noticed on the slide that APNIC was going to do this on the 1 July. He asked for the clarification and whether this is a proposal.
Filiz responded that this is not what APNIC is going to do. By 1 January, 2009 they will do the agreed thing, which is common in all RIRs. By 1 July, if somebody who has been assigned a 4-byte ASN by default within the previous six months, can demonstrate that they cannot use it, they will immediately change this to 2-byte ASN. That is what they passed.
Denis commented that the RIPE NCC will then start issuing more AS DOTs and then have to change more to ASPLAIN.
Rüdiger commented that what is assigned are 32-bit numbers and not representations.
Gert added that people like to think in representations.
Rüdiger said that some people have strange thoughts, including himself.
Gert commented that these are good closing words.
H. Update on the 2007-01 and a new charging scheme from the RIPE General Meeting– Axel Pawlik (RIPE NCC)
Axel gave an update on decisions made at the RIPE NCC General Meeting regarding the RIPE NCC Charging Scheme and integration of the PI holdings into that based on the approved 2007-01 proposal.
Gert added that this is inline with what Andrew de la Haye (RIPE NCC) presented the other day.
I. RIPE Policy Development Process (PDP) Deadlines
Should there be a cut-off time for new proposals before an upcoming RIPE Meeting?
Problem statement and getting feedback from the working group
Gert explained the issues of having policy proposals received later than four weeks before a RIPE Meeting and suggested formal proposals are sent sometime before the meeting and not on the Friday before a RIPE Meeting.
Daniel commented that it is ‘first come first served'. So, if you are too late you do not get space on the agenda but that does not mean anything for the Policy Development Process because this process does not happen at meetings. The meetings are not a formal part of the policy process. So anybody can do anything at any time but if you want space in the agenda at the meetings, the earlier you are the more sure you are that you will get space.
Gert commented that this is technically correct but it is useful to have plenty of time at the meetings to speed up the process of getting feedback that really helps to figure out which way to proceed.
Filiz added that Gert is trying to help the RIPE NCC here regarding the secretariat and that there is no intention to change the Policy Development Process at all. In the RIPE PDP there is no binding with the RIPE Meetings and this is quite special among the RIR regions because the RIPE region is the only one. There is no deadline to submit proposals and this is only a recommendation.
With a formal proposal the RIPE NCC means giving a number to it within the PDP and publishing it on the website and making the necessary announcements on the mailing list and that takes quite a bit of work on the secretariat's side.
Gert added that this is just a point and it is easier on everybody if there is a bit more time to prepare. He repeated that he is not proposing to cut off anything but the experience has shown that too many last minute things mess up the agenda.
Randy commented that as an APNIC Policy Chair he has to read all the policy mailing lists, and that the best thing about the RIPE one is that it is not as bad as the ARIN one. Things seem to be more productive and rational and face to face, which is important and being polite about bringing up agenda items for it would seem to be a reasonable request.
Ray Plzak (ARIN) made a comment that the ARIN process currently has a deadline associated with it but it is not for any mechanical reason and it is not to give the staff time to do things. The intent is to allow any given policy proposal a sufficient amount of time for discussion on a mailing list, so that those people who are not going to be at the meeting have an opportunity to comment on it as well and that the chair of the meeting and the Advisory Council (AC) can use that to get an idea from the broader community. In the RIPE community the total process is focused on the list and not on the meeting. The opportunity to discuss things on the list should probably be the RIPE NCC's important criteria and not whether or not the staff needs to have extra time to get something done.
J. RIPE Policy Document Reworking/Rewording Project at the RIPE NCC
Feedback from the WG - Is this a good idea?
Filiz asked for feedback on whether it is necessary to have a cleanup in the language of the main RIPE policy documents.
Marco asked whether the RIPE NCC is intending to formally use the PDP to publish the revised documents, as there was already some discussion going on about whether or not the actual wording changes should involve the PDP or not.
Gert commented that it will make the process more difficult if, for every formal PDP change, the language of the whole document is adjusted because it will make it more difficult to track what exactly is changed in the way of policy and what is just a cosmetic change. This is not about technical details, it is about the overall wording and document structure, which has even less impact than actually changing the notation for technical aspects.
Gert suggested that the RIPE NCC's help on this should be accepted because it has very skilled technical writers and the mechanics to display the old and new versions of the proposal. He pointed out that he does not think that this should go through the whole PDP process, but should rather be just put up for review of the working group.
Marco added that he is in favour of this and that rewriting some stuff is a good idea, but that it should be a bit more streamlined. One way would be to have a more formal textual change procedure, which does not touch the policy as such but only formatting changes.
Rob commented that the PDP stands for Policy Development Process and beautifying text and changing it into proper English has nothing to do with policy, so the PDP should not be used for that. He suggested that it is given to somebody who has been hired by the RIPE NCC to write technical documents in proper English and publish the revised version not the policy but the wording and if people agree that it is not a policy change but a better way to express the policy, then it is done. We should not spend too much time on this.
He proposed that Filiz and the technical writers take one of the documents, rewrite it and then we can see how that works, then people can have a better understanding what it means to rewrite the document.
Gert commented that if we end up being in a big disagreement on the changes later on, then we might really need to formalise this in a stronger way but for now we should do a light wide approach and see how it works out.
Ray commented that it is important to be careful with this process so as not to change the actual substance of the policy. There should be an editor's control over the entire process from a quality merit standpoint.
Kurtis asked how the changed documents would be referenced.
Janos pointed out that whenever a document is edited, a new document is created and a new number given.
Gert confirmed that every new document will have a new number, the numbers of RIPE Documents are never reused.
Marco asked how it would be visible that it is only a textual change and not a policy change without having to read the whole document. He asked whether there could be some form of demarcation there saying no changes were made to the content of the policy, just textual changes.
Gert added that this is not of relevance.
Ray explained that in the ARIN region they replaced text in one manual because they have it organised by sections and paragraphs. There is a company change log in the archive and a cross reference system so anyone can do research back and forth. He pointed out that staff could consider creating some sort of an index type document or a reference document that would do the cross referencing.
Gert responded that there is the RIPE index text which says 389 is the AS number policy and it obsoletes 266 or whatever the old number was, which is similar to the RFC index document.
Ray added that this is a more generic thing. It might be useful to go into more in-depth discussion particularly when there is a new document that has only a small portion changed but did not really obsolete the previous one.
Daniel (speaking for himself) pointed out that it is very important to make sure that there is only one single current policy document as some people could take an advantage of it and say that there is an inconsistency so they can choose whatever version is more favourable to them.
That means that even when only revisions to improve the text are done, this WG has to sign off on it. If some people feel that there is a material change we either have to take it out or run it through the formal process.
He pointed out that recently the RIPE NCC had a procedural audit of the Registration Services department. If the auditors who had to audit the procedure against the policy found something like that they would just laugh at us and look for the inconsistencies.
Gert agreed and added that the idea is to have it up for a review first.
Filiz summarised what has been said to make clear what the WG thinks is the right thing to do. She pointed out that the idea was to get the community's mandate on this practice. If the community wants to have the language improved, then the RIPE NCC can do that. The intention was to publish a draft, open it for review and use the same drafting mechanism that is used for proposals within the formal PDP.
Although this is not the proposal, the RIPE NCC would still mark the changes so people can see where the changes were made.
Marco asked whether Daniel suggested that the PDP process should be used with a few steps skipped.
Daniel responded that he was not giving a solution but saying what the properties of the solution should be. He added that he personally thinks that the whole PDP process should be used but also agrees to Rob's suggestion.
K. Open Policy Hour
Gert explained that the Open Policy Hour is a showcase for policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity.
Daniel pointed out that he is not expressing any formal opinion of RIPE NCC. He also asked that people in the room understand the difference when he states that he is expressing his own opinions and not those of RIPE NCC.
He asked if the WG would feel better or worse about the RIPE NCC if there turned out to be some inconsistencies/contradictions later between the public RIPE NCC statement and an individual statement from a person working for RIPE NCC.
Lesley responded that she personally values the people who are in the thick of this stuff as their day job having the ability to stand up and share their perspective, but what you want to generally avoid is a situation where it starts to be the case that people feel that if they are not in the context, their opinion is somehow not as informed. That is the difference you can fall into depending on the difference.
Rüdiger commented that there is a space for formal discussion and space for an informal discussion. Censorship always exposes weakness in an organisation.
Daniel concluded that he is voicing his personal opinion. He stated that he wanted to share his concern and at the end see whether there is a formal action needed on it.
Kurtis said that the graphs would make more sense and prove the point better if Daniel had explained where the allocations were going. Are they being assigned to people who already had a lot of address space or are they being assigned to new entrants? He added that Daniel is probably right but some more data would have backed the point made up a bit better.
When talking about fairness, fairness in some sense is the equal distribution and equal access to resources and what Daniel is trying to argue is that all the large allocations were given to people who had massive amounts of address space.
Daniel responded that he is happy to provide more data but thinks that this is irrelevant. He added that no matter whether it is a new entrant or it is an old one, this situation is perceived to be unfair.
Randy said that ARIN did a similar analysis and that for last N years 75% of the address space went to 10 holders. A community of people established in the market has placed a barrier to entry with the excuse of preserving the routing table by “you can only enter if you are big enough to save our router resources”.
Daniel asked the following questions:
Are the scenarios realistic?
Will they cause, or will they like competitors to fight in courts, by regulators, by government?
Are governments concerned about the scenarios and the perceived unfairness?
Do we think it will impact on them?
Do we need to develop policies to address this?
Ray stated that the answer to the first three questions are yes and the answer to the fourth question is up to the community to decide.
Randy agreed with Daniel. Doing something to see that 75% of the last /8 won't turn into what was just shown is a good thing.
Daniel pointed out that he would like to share it more than the last /8.
Sander Steffann (APWG Co-chair) agreed with the research and stated that he has looked at some numbers as well and more than half of the address space the RIPE NCC allocated is going to the few big blocks.
Daniel showed the slides.
Kurtis commented that he is not surprised by what has been shown. The interesting part is to whom that space is going to. He agreed that this needs to be addressed. He pointed out that we are running out of time to discuss how. There are only two RIPE meetings a year so the RIPE community cannot respond to policy needs as fast as other regions can which might be a nice observation to make.
Daniel responded that he does not agree with it, as policies can be made between RIPE Meetings. The PDP doesn't say that we absolutely need a RIPE Meeting. He repeated the question of whether he should go on with it.
Randy stated that it is a good idea.
Rüdiger (speaking for himself) said that the WG should think about it and try to do it, but we should be careful not to do it and not to do it in the haste.
Daniel asked the question whether people would have a problem with the RIPE NCC taking an initiative on this as it is usually seen that the RIPE NCC should stay neutral in the PDP.
He said that he is willing to work on it and also asked for the volunteers.
Randy stated that he is not from the RIPE region but would volunteer to help. He also stated that RIPE NCC members should step up.
Cathy added that this is supposed to be an open policy process and not just the members can participate in that. That is the point of an open policy process.
Daniel concluded that he was waiting for volunteers to approach him during the coffee break.
Gert added that it is scary to see what the use looks like and that he is happy to help in going forward with this.
L. RIPE Policy Process - More Participation
Do we need/want RIPE community polls?
Other ideas
Gert dropped this off the agenda and stated that it will be brought up to the mailing list as time ran out.
Z. A.O.B./General Discussion