November 2006 - address-policy-wg

2006-06 Discussion Period extended until 27 December 2006 (IPv4 Maximum Allocation Period)
by Filiz Yilmaz 30 Nov '06

30 Nov '06

PDP Number: 2006-06 IPv4 Maximum Allocation Period Dear Colleagues, The Discussion Phase for the proposal 2006-06 has been extended until 27 December 2006. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-06.html During RIPE 53, the RIPE NCC was asked to analyse the possible impact of this proposal on address consumption and fragmentation. This analysis has been done and can be found at the URL above. We encourage you to review this policy proposal and send your comments to address-policy-wg(a)ripe.net. Regards, Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

RIPE 53 Meeting Report and Plenary Minutes available
by Paul Rendek 29 Nov '06

29 Nov '06

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE 53 Meeting Report is available at: http://www.ripe.net/ripe/meetings/ripe-53/report.html The RIPE 53 Plenary Minutes are available at: http://www.ripe.net/ripe/meetings/ripe-53/minutes/plenary.html Regards, Paul Rendek Head of Member Services & Communications RIPE NCC

1 0

RIPE 53 AP WG minutes (draft)
by Gert Doering 23 Nov '06

23 Nov '06

Hi fellow Working Group members, below you'll find the draft working group minutes from the R53 meeting in Amsterdam. Please send in your comments, if you think something is not fully accurate... Thanks a lot to Rabia Gawish from the NCC for scribing. Gert Doering, AP WG Chair ----------------------------------------------------------------- Address Policy Working Group Minutes from RIPE 53 Version 1.0 WG Chair: Hans Petter Holen Scribe: Rabia Gawish Amsterdam, Thursday 5 October 2006 14:00 - 15:30 A: Administrative Matters =========================== - Welcome - Scribe - Agenda Finalised. - Minutes from RIPE 52 approved: http://www.ripe.net/ripe/wg/address-policy/r52-minutes.html - Point people to mailing list - address-policy-wg(a)ripe.net Action on attendees to subscribe to the mailing list. B. Elect a New Address Policy Working Group Chair and Co-Chair(s) ================================================================= Hans-Petter Holen (Visma IT) proposed to step down as Working Group Chair (and become a co-chair) due to high work load and too little spare time. Volunteers for these positions would be very welcome. No one came forward. Hans-Petter Holen asked Gert Doering if he was willing to step up as Working Group Chair? Gert Doering (SpaceNet AG) stated that he has been busy with RIPE for the last 7 to 8 years. Since he has been Co-Chair for the last year, he is willing to take over as Chair. He also thanked Hans-Petter for all the work he did for the working group over the last year. And if the WG is willing to have him as Chair then he will volunteer to be the Chair. Andrea Borgato, our Co-Chair, seems to have fallen off the net for a while. Andrea Borgato (Network Service Consulting) stated that he has indeed fallen off the net. He has changed jobs 3 times in the last five month. He has tried to spend some time on his commitment to the WG but has been having problems. Over the last two months he has been reloading himself and have exchanged some opinions with the Chair and Co-Chair. Andrea has decided to continue with his commitment as Co-Chair. Hans-Petter Holen concluded that Gert Doering is now the Chair and Andrea Borgato and himself will continue as co-Chair until the working group finds someone else to replace Hans-Petter Holen. C. Ongoing/Current Address Policy Proposals in the RIPE Region =========================================================== - Accepted Proposals: --------------------- 2005-02 - IP Assignments for anycasting DNS (Accepted) 2005-12 - 4-byte AS Number Policy (Accepted) - Open IPv6 proposals: ---------------------- 2005-08 - Amend IPv6 Assignment and Utilisation Requirement http://www.ripe.net/ripe/policies/proposals/2005-08.html 2006-02 - IPv6 Address Allocation and Assignment Policy http://www.ripe.net/ripe/policies/proposals/2006-02.html Hans-Petter Holen asked the group where they want to go with IPv6? Do they want to look at other regions and see what they have done? They also need to align the p roposal texts. Leo Vegoda (RIPE NCC) expressed concern regarding the policy proposal 2006-02 for point C and how the community wants RIPE NCC to implement what a "reasonable" number is. It has to be plural, so is it a minimum of 2 /48s? RIPE NCC will be delegated to choose the "reasonable" number, but how does the community want RIPE NCC to do that? Hans-Petter Holen thought that there would be a check box in the request form asking the requester if they were going to have a reasonable number of customers, and all that is needed is for this to be checked and the requester would qualify. Leo Vegoda expressed that this would make it very easy to implement for the RIPE NCC. Jordi Palet Martinez (Consulintel) stated that he was going to suggest something similar to what Hans-Petter just did, but would rather ask the other regions that have already taken out the 200 /48 requirement (AfriNIC or LACNIC) and ask them how they evaluate their requests? Iljitsch van Beijnum (RunningIPv6.net) suggested that if we set a rule then it should be a clear one. So either put a number in C (something measurable) or it should be removed all together. Ricardo Patara (LACNIC) stated that LACNIC changed their policy with no numbers, but they have restrictions on the time frame in which the prefix allocated is used which is 1 yea. They also have 2 years set for running services using the IPv6 space. Minimum allocation size is /32 and customers' request get minimum allocation. If they need more they need to provide plans to use this. ?What they also check is the number of services they have and the number of users they have. Ernest Byaruhanga (AfriNIC) stated that they evaluate it the same way as LACNIC. Bernard Tuy (RENATER) is not comfortable with point C. It seems to come to a matter of trusting LIRs or not. Because the LIRs are the ones that are going to request this, so what are is the WG trying to do? Hans-Petter Holen adds that what AfriNIC and LACNIC do is set a requirement for the LIR to announce the prefix in a certain period of time, and that they actually provide services using IPv6 and have enabled their DNS for IPv6 web services and thus within the first year they are already having some customers. Gert Doering states that the community trust the RIPE NCC, but the it needs to put up rules that reflect the consensus reached, which is what the community wants. The RIPE NCC then implement the policy that the community puts in place. As for the specific wording "reasonable number of customers" it is a tricky one indeed and the community needs to rethink it. Another issue is in the proposal for the removal of the 200 /48 assignments needs more discussion, because there has been no consensus reached on this one. Regarding the IPv6 policy change proposals, Gert noticed in the proposal from Geoff, which was to remove the fixed size /48 assignments, that the working group is not very careful in spotting the results, it doesn't matter the size of the assignments, because the LIR should decide how much he wants to give to the end sites. This is also another thing that the community needs to rewrite and express exactly what the community wants. Jordi Palet, understands the fear of removing the 200 limit because it could generate an explosion in demand, but to look at what happened in the other regions that have implemented this, they have had a decline in requesting IPv6 allocations. He doesn't believe that it will change the situation, but will provide access to prefix to small ISPs which can have a few big customers, and why are they not allowed to get IPv6 resources? Hans-Petter Holen clarifies that there is no objection is to the way we are changing the fixed number, but the objection is making the change in this particular way. Are the proposals in other regions more specific? Ricardo Patara states that the policies in their region, LACNIC, are not specific and it is up to the hostmaster's evaluation. Max Tulyev (NetAssist LLC) explained that in a real situation, Ukrainean small ISP (small) can not find any upstream provider (LIR) in Ukraine that will provide them with IPv6 because none of them will qualify under the current policy of 200 /48 as minimum requirement. So good practice, for this situation, is to remove it totally. If one client of the LIR needs IPv6, then give the LIR an IPv6 allocation. Hans-Petter Holen concludes that the text of this proposal has to be changed so we will discuss this further with Jordi Palet Martinez and then bring it back to the mailing lists. Geoff Huston (APNIC) stated that one thing they did strike, in APNIC, is precisely the issue of comparing the two proposals 2005-08 and 2006-02, down in slide 13, that they actually have now the idea that end-site are an LIR decision but also in the APNIC policy they have /48 in another place. ?Geoff believes that Jordi might want to consider what an end-site is, thus replacing /48 with end-site, so this would reflect whatever an end-site is, other than a /48. ?This way, the end-sites can be looked at as such and not as /48s. This will give freedom to LIR for the size of the end-site. Hans-Petter Holen finds this a very good point, as two proposals are attacking the same text. Wilfried Woeber (ACOnet, DB WG Chair and NRO NC) wanted to make the same comments and he believes that all three proposals need some serious reworking. These two policies end up mixing things that are not really related to each other. There is no real relationship between the HD ratio on one end and offering the freedom to justify a /48, there should be no aggreement to different aspects of the proposal. Geoff Huston stated that the intention of 2005-08 is to define what full is when and LIR comes for more space. HD094 is not enough, this is to say 094 of what? Gert Doering agrees that this is the part that is not yet clear Geoff Huston stated that in APNIC there was a different proposal, first proposal was to remove the /48 as a fixed point but then how do you figure out what full is, because we do not use consistent end-sites? If we say 80% of the /32 means 80% of the space. If you take away the fixed end-site, how will you count what full is? What is the HD ratio going to be applied to? We will apply it to a /56...what does a used allocation really means? How do you do the mathematics to say it is over the threshold? Hans-Petter Holen stated that the working group has spent quite a while discussing this proposal. ?Geoff Huston made a presentation, in 2005, before this was finalised, more than a year ago, where there was concern with the allocation requirement and additional allocation requirement. What we agreed then was that we had to change this quite fast before we burn this too quickly. He then also asked the room if anyone here was not in favour of changing the HD ratio in order to conserve IPv6? Only one against it. A lot in favour. Then for those who don't care, Hans-Petter asked why. Unidentified person feels that the WG has wasted so much time discussing this. There is plenty of IPv6 space so let's take this to the final call and move on with the other policy proposals. Hans-Petter Holen concluded that he will consult with those who sent in the proposals to change the text and then reach the last call. 2006-01 - Provider Independent (PI) IPv6 Assignments for End Users http://www.ripe.net/ripe/policies/proposals/2006-01.html Hans-Petter Holen asked "do we want PI IPv6?" Max Tulyev showed interest in PI IPv6 and that it must be implemented for a maximum of 3 years per assignment. It might also be cheaper or free for 1 - 2 years. As for experimental hosting, if they will only do internet content and there will be a reason to connect to IPv6 network then get IPv6 space. This way it is much cheaper and permanent. Jordi Palet Martinez clarified that the temporary assignment is not for the max of 3 years, but 3 years after the community has reached an agreement for using those assignments for alternative technical solutions. The second thing is that in all the other regions IPv4 PI customers are charged and have a contractual relationship with the RIR. This is failing in the RIPE region because we have almost 50% of the delegations being PI and there are no contractual relationships between the actual user and RIPE NCC and this will affect the billing category of the LIR (membership), so this needs to be corrected. Max Tulyev disagrees with the trial period of 3 years, because for the renumbering of 10000 of domains when changing providers. ?They need to do periodic charging for this space because people stop using it or they are out of business or the network changes and they forget about it and this space is not returned to RIPE NCC and there is yearly billing. Gert Doering agreed that having a contract between PI holder and RIPE NCC is a good thing, because RIPE is different from the other reasons, but this will be discussed further at the end of this WG in the PI for IPv4 slot. Something else to be aware of is assigning /32s to PI holders, why do other regions use /48 for PI holders, why would a PI holder get the same space as an LIR and not as an end-site? Unidentified speaker agrees with Gert, if we are to allocate resources to non LIRs, then we will be changing the RIPE NCC activities on the long term and this needs to be thought threw. Hans-Petter Holen then concluded continuing this discussion on the mailing list. 2005-08: clarification on text and move to next call: 2006-01: back mailing list 2006-02, will review with Jordi for changes. New IPv4 Proposals: ------------------- 2006-04 - Contact e-mail Address Requirements Hans-Petter Holen summarised this proposal that everybody should have email addresses (active ones) that they register in the RIPE DB as the contact for each object/resource registered. Max Tulvey agrees with this, but asks what should happen if people do not do this? Hans-Petter Holen asked if we require all customers to have their own abuse addresses or do we use the providers? Max Tulvey asks again what will happen if people do not do that? Hans-Petter Holen then suggests that they can then not make allocation because this field is mandatory. Max Tulvey then stats that it needs to be made clear that if they do not do that, then RIPE NCC will do that. Hans-Petter Holen asked if RIPE NCC should revoke assignments if the email address is not working? Gert Doering then stated that if you do not answer your email (mentioned in RIPE DB) then you should not have this address. Hans-Petter Holen asked RIPE NCC how they would implement this. Leo Vegoda (RIPE NCC) informed the WG that this is also being discussed on the anti spam WG, and that it is not a good thing to define a working contact email address. ?If RIPE NCC can send an email to this address then it is considered to be working. Because with the 4 thousand members it will require too much human power to check them manually, thus becoming more expensive for the members. Hans-Petter Holen explained that the next level would be to make the abuse attribute mandatory on the RIPE DB objects. The highest level would be for the RIPE NCC staff to chase those who do not reply to their emails, but this is not what we want to propose to the RIPE NCC. Rob Blokzijl (RIPE Chair) said that it is an example of good intentions and bad consequences, but if the proposer intends to facilitate fighting against vaguely defined abuse, if i were an ISP and confronted with this I would think "what a bunch of silly people:" I'll set up procmail and fill in this mandatory field, but it doesn't seem to be a proper way to do this. Again, this is a rule that can not be enforced on our poor RIPE NCC . Wilfried Woeber: Rob said it all, am I allowed to put president(a)ukraine.su? Hans-Petter Holen will feedback this to the one who proposed this and see where we go from there. 2006-05 - (IPv4) PI Assignment Size Hans-Petter Holen gave background is when you request pi now you only get the ones you asked for and are going to use, even if less than /24. Proposal here is that if there is a routing issue then it should be 2 /24s instead. Wilfried Woeber: has a very basic problem with installing a minimum assignment size on a particular policy and not having a minimum size for another policy, this creates an unbalanced situation where we have to bother our customers applying for /25 or /26. Routing problems or any interaction with routing should not have any impact on the minimum assignment for IP address blocks. Iljitsch van Beijnum stated that that would be insane as having the minimum physical requirements for routing that would cost more money interact with the nice game of giving out prefixes, we should be able to do that in any way we want and those that need buy bigger routers if they can't handle it. Lars-Johan Liman (NETNOD) to have an address allocation policy that refuses to involve itself with any degree in the current practises on the Internet is probably not a good idea. The world doesn't work like that. Ger Doering, wants to agree, but traditionally the point of view in the AP WG is that we get involved into what is routable and what is not, but it seems that this leads to people lying to the RIPE NCC when requesting PI space to get a /24 to get a routable block or do we want a policy that reflects people's needs. And this goes hand in hand with the generic PI restructuring. Lars-Johan Liman said that the obvious is true, the routing operational people can not instate operational practises that totally step away from the address allocation policies and that there must be a middle ground, so this is not a one-sided problem. Max Tulyev when somebody asks to lie to RIPE NCC and ask for more space for routing reasons, but there is a lot of space that is less than a /24 that can actually be used maybe we should not speak about minimum assignment size /24 but change that rule that we do not have to ask the RIPE NCC for more address space for routing reasons excluding this situation, but for globally routable PI. Sander Steffann (Computel Standby BV) feels that this is going in circles, ?you hand out assignments and people don't want to accept them so they do not to accept it so they start to filter at /24 level and then people ask for bigger assignments....and it goes on and on until they become LIR. Max Tuley believe it is technically impossible to filter /23 now because you will loose connectivity with a large part of the internet so some ISPs will come and beat you the /24 has no problems with the global routing table, but the ;/25 has problems, which is why lots of people go for requesting a /24 Hans-Petter Holen decided to take this back to the mailing list. 2006-06 - IPv4 Maximum Allocation Period (misleading title) Axel Pawlik (RIPE NCC) said that looking forward we see that on the afternoon of 18th of July 2012 we are going to run out of IPv4 addresses at RIR level, Geoff Huston says so. What will happen then? Axel doesn't believe that anybody will start a war but he would like all the ISPs, LIRs and RIRs to harmonise the time for which allocations are made to LIRs. There was a remark made regarding conservation of addresses, but this is not the intention of this proposal. The idea is to harmonise the policies where possible. Hans-Petter Holen stated that there are two issues raised here 1) Harmonisation of address policies across the regions, which is probably something that the working group should start looking into in a more systematic way, why are they working different? 2) We need to start planning for 2012, or whenever that is to prevent the war. We still have time to figure out what to do when we get there. Iljitsch van Beijnum asked if the idea behind that policy would be that we not have unnecessarily large numbers of prefix in the routing tables? Axel Pawlik explains that the idea behind this policy is that it would be really ugly if one region of the world is sitting on piles of address space and the others are run dry. Iljitsch van Beijnum but wouldn't that happen if you give them space for a long time. If you look at the big chunks of space they are with the telecom companies (with telecom in their n name), they should get smaller blocks and if they project that they are going to use those addresses then they can get more space. ?Also the impact of this on the routing table is zero. Rob Blokzijl made a remark that global harmonisation of policies is nice, but it is not a goal, we should realise that there are different regions in the world with different economies and their problems are solved with different rules, based on real regional needs. We should not do harmonisation for harmonisation's sake, where possible yes, but there is a reason why we now have 5 different RIRs. Hans-Petter Holen challenged Rob Blokzij's statement and asked why it is 3 months in LACNIC 6 in the US and one year in APNIC and 2 years in AFRICA and Europe? What is the similarity between Africa and Europe and what is the similarly between LACNIC and ARIN especially requiring LACNIC to have a much shorter planning period? Rob Blokzijl stated that they all came from the same source. Geoff Huston clarifies that they may have come from the same source but they certainly have variation in outcomes and certainly some studies on this are quite interesting. Currently in IPv4 over the last year and a half RIPE NCC allocates about 35% of the IPv4 space that is allocated from the system, APNIC allocates around 30% and ARIN allocates around 25%. This doesn't correlate precisely to those differing periods but Geoff has a suspicion that they are related and he is going to do some work going through the files to see if there is a correlation between the relative consumption rates and the LIR allocation expected life times. Hans-Petter Holen stated that when working for his second LIR he was asked to prepare a budget for a year and I was shocked as he couldn't see how he could plan for 12 months, as his planning horizon is 3 months or less. At the same time he went to RIPE NCC with the 2 year plan to get the IP addresses. His final question was to the crowd "can you trust those figures from me when i can't make my financial budget for more than 3 months?" Ricardo Patara gave an update that LACNIC has just approved a different time frame for the additional allocation of 12 months. Hans-Petter Holen concludes that the address policy working group needs a bit more time to discuss this. He also stated that there is a possibility that we need a study to see the reason behind those differences. He also stated that maybe we should change this for the sake of an experiment to it's effect on the consumption rate. Hans-Petter suggested that we try this out for a year Geoff Huston stated that you do not need to change the policy in order to understand what it's effects are. You actually have a rich enough database right now of what you've done so you can simulate this quite easily. Hans-Petter Holen suggests asking the RIPE NCC to simulate this as what would have happened last year if this policy had been in place. Geoff Huston agrees that this is a reasonable request. ACTION ON RIPE NCC: Using the information in the RIPE Database, simulate the scenario with this policy in place over the last year. 2006-07 - Minimum IPv4 Assignment Window Leo Vegoda (RIPE NCC) presentation: Minimum IPv4 Assignment Window http://www.ripe.net/ripe/meetings/ripe-53/presentations/ipv4_assign_size.pdf Gert Doering is not feeling very happy about this proposal, he is not opposing it, but as a member of the group he sees some problems, yes you have spent quite an enormous effort on training, those that have been interested in the policies they would have read up about them over the last 10 years, so having lots of good training doesn't help, can't be bothered to send someone on a training course, nor that an LIR has enough people/time to send people to those trainings. The other thing is that you say that they might not be able to get a new allocation; the question is who is hurt by that? In the end, this will hurt the end-site. New customers standing in queue to get address space but they can't get any because the LIR hasn't done the proper administration. ?This can hurt the customer-LIR relationship. Gert would aim for a compromise, like start with a /24 and then move the AW up, but starting with a /21 for someone that hasn't demonstrated to have an understanding of anything, it is not correct. Iljitsch van Beijnum asks what are the statistics for the 2nd opinion requests? Leo Vegoda refers them to printed handout on the handouts desk, there is a distribution chart for all the recent kinds of requests that we get. But two thirds of the requests that we get are 2nd opinion. Iljitsch van Beijnum explains that when you get a 2nd opinion request you get: - no way never - sure no problem - no, we need more information: He then asks Leo how many of those replies are "sure no problem, go ahead" Leo Vegoda informs that he can produce statistics on that to check. Iljitsch van Beijnum then suggested that if it is 99 % then it would be no problem for this proposal. Iljitsch van Beijnum also asked why we don?t keep the minimum at 0 and increase when needed. Because with this proposal if you have a repeating offender then you can not take away the AW, like you can now. Leo Vegoda explained that they do have a system for regularly looking at the AW's of all the LIRs that send in requests and raising their assignment windows. The key thing they wanted to do was to be upfront and honest, they can go and change our practice to dramatically increase the rate at which AWs are raised, but if they give the LIRs the AW standard. Leo would also be more concerned if they raised the AWs faster than if there was a default minimum. Because when saying that the AW is zero, /24,/22,/20...etc then they are giving positive reinforcement to someone and saying that they are doing something good. But if this is done to an LIR after just sending in two requests, then they are going to be shifted very fast and will be given a false confidence that they know what they are doing, whereas if you say" you have this responsibility, use it wisely" they would be more careful and more responsible. Iljitsch van Beijnum clarified that Leo would be doing just like Gert said, as in throwing them into the deep end and seeing if they can swim. This would be pushing out the problem to the LIRs. Leo Vegoda states that this is not driven by workload, I do think that you raised a good point that if you give someone the freedom to hang themselves and they made loads of assignments, and they have done it all wrong, then it would be painful for them and their customer base. However, RIPE does approve Axel's proposal, for 1 year allocations, then people would have less address space to damage themselves, thus the impact reduced. Iljitsch van Beijnum asked what would happen to the end-user if the LIR really screwed up and gave way too much space, would they have to give it back or would they be able to keep it? What would happen then? Hans-Petter Holen summarises that there are two opposite views, like we had with the Audits, and we introduced assignment windows for a reason. Now the situation has changed. We also need to look at what happens with the 0 AW, because with his colleagues in his previous job, they went and assigned space and didn't request it and had to do a huge clean up when they needed more space. The key here is that we need to find the right balance, so we need to take this to the mailing list. Action point on RIPE NCC is to get stats on the 2nd opinion requests for the "sure go ahead" advice. D. Update on Global IANA/ICANN Policies ======================================= IPv6 ICANN to RIR Distribution Policy Update E. Ongoing Policy Work in Other Regions Presentation in the Plenary Plus discussion time in the working group slot Two things where done: 1) When the policy was passed from the LIRs the address council reviewed whether the policies had been followed in all the regions 2) Upon request from the ICANN Board we gave them some advice on the aspects of this policy and based on that, and the advice of other supporting organisations, the ICANN Board then gratified this process. The other outcome that could have been of this was that if the ICANN Board hadn't gratified this then they would have send it back around through all the regions. which they didn't. With this Hans-Petter thanked the two Board Members that we have with us here for their contributions with this. The practical aspect here is that the /12 allocations have been requested and received by the RIRs, so it is now in operation. Z. AOB ====== -PI --- Hans-Petter Holen asked "Should there be a contractual relationship the end-user and RIPE NCC? And, should an end-user get pi via the LIR or should they get it directly from the RIPE NCC? If the later is agreed to then this is a matter for the RIPE NCC Board to device a fee structure for that. Gert Doering stated that the RIPE NCC is allocating more chunks of pi than they are of pa space, even though this doesn't have a big impact on the numbers that are being used, but there is a large impact on the routing system. PI seems to be easy and convenient to get while PA is costly and harder to get. Thus there is a big imbalance. The RIPE NCC is also working on the certification stuff and if they are to give a certificate that this address space is yours for the next two years, it is helpful to know who you are. Gert feels that it would be useful to have a relation between the pi holder and the RIPE NCC for the distribution part. Gert also stated that we as a WG do not decide the fees and the RIPE NCC general membership do not decide on the policies. The idea it to have two ways of getting PI space either via an LIR (LIR has to stand up for it and pay for it and pay yearly for it) and if the customer moves to another ISP the PI has to move with the customer. If there is no LIR standing up to make sure that the information of the customer is correct, the end-site holder can have a contract with the RIPE NCC and get an address certificate for the space and they will also pay RIPE NCC for that. The fee should not be a high amount, but some basic service fee, like Euro 200 is not a seriously big amount for someone who is doing networking. Leo Vegoda pointed out that the RIPE NCC has a stewardship responsibility with regards to the address space. At the moment RIPE NCC is currently assigning space directly to the end user but have absolutely no communication with the end-user, which is the business processed agreed to by the community. Max Tulyev stat that there is an established process, where LIR contacts and works with the end-user and the end-user continues to use the space, LIR makes sure that the end-customers are using the address space by contacting them by email and making sure they are paying their bills. Because there are too many different cultures and tax laws all over Europe, it would be more comfortable for the end-users to deal with local people and local ISPs. Gert Doering agrees, but what happens if the end-user leave you (as an LIR) and goes to another LIR? Gert doesn't want to deal with their PI business, and wants to have another method for the contacts. Max Tulyev stated that PI space issues are not related to the connectivity services they provide, there is no relation. Changing connectivity is not a reason to change the LIR responsible for this PI block. Gert Doering asks what would then happen in an extreme case like the LIR goes out of business. In this case there is no one in contact with the PI holder nor do we know if the address space is still in use. Max Tulyev suggests that we have another policy for when the PI block should change LIRs. For the end-user need to know what happens then and how it should happen. Rob Blokzijl sees that we need some form of established relationship between the holder of the pi space with RIPE NCC, whether direct or indirect, via a cooperating LIR. Secondly, if this whole the certification system comes into place and everyone is using it, then this might be a very attractive tool in formalising this relationship, including the moving of PI holder from one LIR to another and when loosing an LIR. Because the need for a certificate will still be there. This will also give us the incentive of keeping in touch with somebody. Hans-Petter Holen concludes that we will need a final policy proposal on the mailing list. We already have a volunteer. Announcement: -------------------- Filiz Yilmaz (RIPE NCC) stated that there have been requests and feedback on the impact of some of the policy proposals discussed here today, also during the plenary session. Filiz said that they have been thinking about this and now they are in the planning phase of this work, soon they will be putting some additional work for when a proposal comes in to let the community know if there is an impact at that moment. They are thinking of doing that on the review phase level when questions are a bit more mature. Hans-Petter Holen extended the Thank You to Filiz Yilmaz from the RIPE NCC, for preparing this presentation and supporting all the working group chairs with preparing different proposals. Filiz has also agreed to give a presentation in the plenary session on Thursday and join in discussions about individual proposals in the working group session. Filiz Yilmaz acknowledged the Communications Department's help with the proposals and they got an applause too. -------------------------------------------------------------------------

2 1

2006-04 New Draft Document Published (Contact e-mail Address Requirements)
by Erics 20 Nov '06

20 Nov '06

Hi Community, I´m a bit surprised to read a draft document for this proposal. If I recall the informations I got from RIPE-53 meeting - unfortunately I couldn´t be there myself - the discussion regarding the proposal 2006-04 endet with "not practicable". And this is exactly what I think about this. For bigger LIRs it is not possible to provide an e-mail address, unless this address could be the "notification-" or "changed-" address, which appears in each inetnum object anyway. If this is ment, this should appear clearer in the draft document. BTW: I´m missing the RIPE-53 address-policy-wg-minutes kind regards Eric Schmidt _________________________________________ Deutsche Telekom AG T-Com Headquarters Network Information Center Ammerlaender Heerstr. 138, D-26129 Oldenburg +49 441 234 - 4592 (phone) +49 441 234 - 4589 (fax) E-Mail: EricS(a)t-com.net <http://www.t-com.net/> http://www.t-com.net

1 0

SPAM filtering at RIPE NCC
by Brian Riddle 16 Nov '06

16 Nov '06

[Apologies for duplicate e-mails] Dear Colleagues, Today, we implemented measures to combat spam on our mail servers. The measures will apply to both e-mails sent to RIPE NCC mailboxes and the mailing lists hosted on ripe.net. These measures will lead to short delivery delays for some of your e-mails to us and to the mailing lists. Regards, Brian Riddle IT Manager RIPE NCC

1 0

2006-07 – Minimum IPv4 Assignment Window
by leo vegoda 09 Nov '06

09 Nov '06

Dear Colleagues, During the Address Policy WG session at RIPE 53, we were asked to provide statistics showing - how many of the requests to make a PA assignment involve discussion with the requester; and - how much discussion takes place in those requests. We have prepared a set of statistics showing the number of rounds of messages in a ticket. Please note that tickets often include messages that are not directly related to the specific request. For instance, when an LIR is eligible for an additional allocation discussion can also occur on how to register something in the database, or we may remind them about an unpaid invoice. We looked at all the tickets where we approved PA assignments of prefixes up to and including /21 during the last three complete months of July, August and September in 2006. This was a set of 1100 tickets. The attached graph illustrates: - 80% of requests are approved immediately, or following just one exchange - 15% are approved with just two or three messages being exchanged - 4% of tickets involve a significant amount of discussion These figures show that only a small fraction of LIRs need significant assistance with their decision making. We will be able to dedicate significantly more time to this small group of LIRs if the minimum Assignment Window is raised. I hope you find these data useful when considering my proposal. The full table of results: Exchanges Tickets 0 673 1 214 2 118 3 48 4 11 5 20 7 6 8 4 11 4 12 2 An archive (available as a stream) of the RIPE 53 Address Policy WG webcast is available from our web site at: mms://webcast.ripe.net/ripe-53/ap.wmv and my presentation can be found at: http://www.ripe.net/ripe/meetings/ripe-53/presentations/ ipv4_min_aw_size.pdf Regards, -- leo vegoda Registration Services Manager RIPE NCC

3 3