Hi Christopher, Tks again for your responses. Below, in-line.
Regards, Jordi @jordipalet > El 18 feb 2024, a las 22:46, Christopher Hawker <[email protected]> > escribió: > > Hello Jordi, > > There are transfers fees that in one side, cover the work-load done by the > staff, and the EC could set specific temporary transfer fees if this becomes > a problem. > > If the EC determines that setting a fee to cover the increase in workload > then yes, this could indeed resolve the issue. > [Jordi] Even if they don’t change the actual fees, I will tend to believe that they have already adjusted those fees so they cover the human resources cost for each transfer, so if “more” transfers are done (let’s say for example, 4-5 transfer per year of the same resources set), costs are lower and lower so there is some incomes increase. > I understand this is the case as the secretariat impact analysis didn't > mention this as a possible issue. > > My reply was sent prior to the Secretariat sharing their impact assessment, > so some points I've raised may not necessarily have been identified as an > issue by them. > [Jordi] They can update the IA, or even respond to this specific point. Let's see. > For example, if a conference organizer or a big temporary setup needs the > addresses for just one month, why not? > > If resources are only needed for a month, is it worth the trouble going > through the transfer process for just that one month and paying any required > fees? > [Jordi] Why not? I will say it is a case by case, but we are defining general rules that allow as many cases as we can. What about conferences or events that may need the resources even for just one week. I guess they will need to deploy the equipment before, test it, then dismantle the event, etc. I’ve done this several times for events, and this is a way to make this work if you need your own set of resources, instead of using the ISP ones, for example, because you have multihoming. This is the case for example of the IETF, the only difference is that they already got many years ago their own ASN, IPv4 and IPv6 and they run BGP in each event venue; other organizations or events for sure haven’t forecasted the need so they don’t have their own resources already. > I agree that in most cases, it will become a 1-2 or even 3 years period, but > why restricting special cases that may need more? > > As mentioned in my original remark, if the intent of this proposal is to > accommodate for networks to transition to a native IPv6-only network then 3 > years would be more than sufficient. In what circumstances would providers > also need to transfer space for a period longer than 3 years? > [Jordi] Believe me, I’ve seen providers that required more than 2-3 years for the transition and they may prefer a temporary transfer instead of a permanent one, because they way you account for that cost is different and has different fiscal advantages. In general accounting for a leasing (temporary transfer) is much better in terms of taxes than a “purchase” (permanent transfer). > The proposal already restricts it to a maximum /22, so I can't see the misuse > that you mention. May be you can explain it? > > If the intent is to support IPv6 transition, the misuse could be that people > may use the proposal (if passed) to transfer resources for other purposes. > [Jordi] I’m not saying that the intent of the proposal is only for transition (even I foresee it as the most important one). There may be other reasons, and I don’t think we should restrict that. > I've seen, worldwide, many cases where members with shorter IPv4 prefixes, > even obtained recently, didn't plan correctly and timely for the transition, > because they didn't forecasted well their expected growth, etc., so I don't > think that will be good. > > I agree that potentially the requirement for holdings no shorter than a /22 > v4 prefix could be struck out, however the time in which they were obtained > should (in my view) remain. I appreciate that it may be difficult to make > resources available for IPv6 transitioning on an existing network and an > operator that holds a /22 v4 prefix may determine that they require a /23 v4 > prefix to successfully transition but having said this, network operators who > have obtained space in the last two years should have very well factored in > the ability to transition to IPv6. > [Jordi] I will love to see everybody forecasting so well, but is not real life, unfortunately. > Regards, > Christopher Hawker > > _______________________________________________ > SIG-policy - https://mailman.apnic.net/[email protected]/ > To unsubscribe send an email to [email protected] ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
