<div dir="ltr">Dear Carlos,<div> </div><div>What I was trying to say is that if we try not to complicate things then we can say there were IPs given to LIRs which they would distribute to the end-users and those IPs should remain under LIR's control and there were IPs given to end users through LIRs. The status of the IPs is just a text. Everything has to be based on contracts between RIR -> LIR and LIR -> user. It is not important what the status was, the IPs were and are used exactly the same way. And you are wrong, having a PA assignment doesn't restrict you at all. Everybody accepts /24 announcements no matter their status and it's no longer the case with RIPE's recommended longest prefix. That was changed to /24 long time ago.</div><div> </div><div>So today if someone has a /24 assigned PA from an LIR, he can announce it through whatever ISPs he wants and doens't need to have anything to do with the LIR except from the agreement through which he got the IPs from the LIR.</div><div> </div><div>As for the PI assignments that were made from PI allocations, the purpose was indeed to make a distinctions between multihomed users and those who used only the LIR as their upstream provider, it was supposed to help with the aggregation but it was never respected. Always there have been PA assignments used exactly the same way as PI assignments and, even though I had objections at the time, NCC said that's perfectly ok.</div><div> </div><div>Now, if the PI assignment holder doesn't have a contract with the LIR, then what are we talking about, he should return the IPs immediately. If he has an agreement, they can continue happily with that agreement even if the status would change from PI to PA. </div><div> </div><div>From my point of view it's a simple solution to a not very complicated problem. But as I mentioned it's always about the money. I have no interest in this, I don't have any PI blocks (either allocated or assigned) and I support the logic behind the process. I would consider it an abuse if NCC would interfere between an LIR and it's customer and I don't think that we, the RIPE community, should support something like that. By adopting a policy which would probably break some contracts could result in some legal complaints. And why are we doing this ? Just for a few silvers ? </div><div> </div><div>Ciprian</div><div> </div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Oct 21, 2016 at 12:30 AM, Carlos Friacas <<a href="mailto:cfriacas@fccn.pt" target="_blank">cfriacas@fccn.pt</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi, On Thu, 20 Oct 2016, Ciprian Nica wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I agree with Daniel. A well defined problem is half of the solution. </blockquote> +1. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> In this particular case the problem arises because the main question is who makes the money, the LIR or the end user. </blockquote> And when noone is really "making money", but is just using the number resources as they were originally distributed...??? <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> In the past there have been PAs used as PIs </blockquote> Yes. But that doesn't qualify as "a mess" or "swamp"? <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> so technically I think the "allocated" part should be the one that's more important, therefore I would support the replacement of allocated pi & unspecified to allocated pa. </blockquote> Why would you want to change status of something that belongs/is in use by other organizations? With or without agreement from the end user (and LIR)? <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> If you ignore the greed then changing the status would not make any difference. </blockquote> Maybe we need to revisit how this "issue" was created in the first place... (and when). <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Ripe has a relation with the LIR and the LIR with the customer. </blockquote> 1st part is true. 2nd part i really wish it was true... this (ALLOCATED PI/UNSPECIFIED blocks) is not LEGACY space, but there are some tricky details too... :-( <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Changing PI to PA will not affect the workability of the IPs nor the relations that are already in place. </blockquote> Yes they can be..... and this can probably be observed from the routing info. Example: LIR manages /16, everything is PI, so every /24 is already "globally routable". Once that /16 automagically becomes PA, anyone in the world can happilly reject any /24 from the /16. This is even harder if end users are not using the same upstream and/or don't even have any relationship with the LIR -- can happen, does happen because this goes wayyyyyy back. Please keep in mind this still comes from the 20th century... ;-) <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Changing them to regular pi assignments would break the link between lir and customer and give the enduser a possibility to make money, nothing more. </blockquote> ??? Afaik, they are already PI. The link is (probably) mostly broken, and, imho that's the core of the "monster" we have to deal with ;-) Cheers, Carlos<div class="HOEnZb"><div class="h5"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Ciprian On Thursday, October 20, 2016, Daniel Stolpe <<a href="mailto:stolpe@resilans.se" target="_blank">stolpe@resilans.se</a>> wrote: Thanks for the update and summary Sander! I have been thinking a bit both during this particular case and in general about something from another working group. Job introduced the concept of "numbered work items" with several phases and where the first phase reads like (quote): phase 1: problem definition In this phase as group we'll work on formulating an exact problem definition: text goes back and forth in the working group, example cases of the problem are provided. In a 2 or 3 weeks timeframe the chairs declare consensus on the problem statement of NWI. phase 1 output: clearly defined problem statement, or a conclusion we cannot agree upon a problem statement definition. If the latter is true, the NWI cannot proceed to phase 2. (end quote). Maybe it is only me but I have had the feeling sometimes that we are not completely sure what problem we are trying to solve, and that we can sometimes start with proposing a solution before the problem is well defined or agreed on. I think I am correct that the problem in the particualar case is unclear (unspecified or pi that is maybe not really pi) and/or incorrect (pi that is really pa) data and according to that I agree with Sanders summary below. Cheers, Daniel On Thu, 20 Oct 2016, Sander Steffann wrote: Hello working group, The discussion on how the RIPE NCC should deal with ALLOCATED PI / ALLOCATED UNSPECIFIED has died down a couple of weeks ago. We therefore think that it is time to draw conclusions. A total of 16 people and the working group chairs participated in the discussion following Ingrid?s proposal on how to handle the situation of PI assignments within ALLOCATED PI / UNSPECIFIED. Five people (Sergey Myasoedov, Radu-Adrian FEURDEAN, Nick Hilliard, Leo Vegoda and Hank Nussbacher) created side-threads without expressing an explicit opinion on the proposal. The remaining 11 people were: ? Patrick Velder ? Larisa Yurkina ? Randy Bush ? Enno Rey ? Herve Clement ? Stefan Schiele ? Markus Weber ? Carlos Friacas ? Leo Vegoda ? Andre Chapuis ? Daniel Stolpe ? Oliver Bartels Four participants stated that they represent organisations holding such allocations (Larisa, Markus, Andre and Daniel). Three people indicate that they are related to PI assignments within such allocations (Enno, Stefan and Oliver). Five people stated their clear support for the proposal (Enno, Stefan, Oliver, Patrick and Herve), mainly to increase clarity for PI assignment user and to support correct registration. While there was no explicit opposition, Larisa and Andre stated that it would create extra workload for their organisations while they don?t really see the gains of such change. Larisa suggested to introduce alternative RIPE database statuses instead. The other participants had mixed opinions: Markus understands the advantages for PI assignment users, but was concerned about the extra workload for his organisation. He suggested to somehow lock PI?s within the allocations and force the PI holders to sign contracts, but recognized that this idea might be not practicable. Daniel could life with the change from ASSIGNED PI to ASSIGNED PA but agreed with Larisa and Andre that there is actually no issue to be fixed. Randy supported the aim of correct registration but also stated his concerns about the routing table and that some PI holders might not be happy to pay a fee for the sponsoring LIR. Carlos also stated his concerns for the routing table. Conclusion: Five people supported the proposed approach, four people saw some advantages but also were concerned about side effects, while two people didn?t see the need to take action. There were three opposing arguments: - big workload compared to the gain - increase of the routing table - PI holders might not like to pay a fee for the sponsorship The first opposing argument can be considered as addressed as three PI users confirmed that a clarification of that issue would be very important to them. And the RIPE NCC can support the LIRs, for example making bulk updates on route and domain objects. The second opposing argument, could be considered that this is not directly related to the fixing of the registration. Already now all but one of the allocations in question contain more specific route advertisements. Also in the extem case that all ASSIGNED PI within the allocations would be carved out, we would talk few thousand new entries in regards to 628K total routing entries (normal growth of the routing table is around 2K per week). The third opposing argument was addressed by Gert, stating that PI holders appreciate to pay a small fee to be sure that their resources are correctly registered. Based on all of this I feel we have a strong enough mandate for the RIPE NCC to move forward, but some concerns about the amount of work involved. I therefore would like to ask the RIPE NCC on behalf of this working group to move forward with their plan, but to extend the proposed deadline of the end of January 2017 by a few months (the end of Q1 2017) to give LIRs a little bit more time if needed. Cheers, Sander APWG co-chair _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 <a href="mailto:stolpe@resilans.se" target="_blank">stolpe@resilans.se</a> Resilans AB Fax: 08 - 55 00 21 63 <a href="http://www.resilans.se/" rel="noreferrer" target="_blank">http://www.resilans.se/</a> Box 45 094 556741-1193 104 30 Stockholm </blockquote> </div></div></blockquote></div> </div>