This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Future of Re: [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)
- Previous message (by thread): [address-policy-wg] [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)
- Next message (by thread): [address-policy-wg] Future of Re: [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Garry Glendown
garry at nethinks.com
Thu Jun 11 14:57:09 CEST 2015
>> I will readily admit that I can not come up with a text which prevents >> abuse _and_ allows for valid operational needs, though. > Indeed. Mergers & acquisitions are real-world business events that APWG > cannot affect. I see a big nut to crack on how to address abuse via > "illegitimate" M&A, including figuring out what is and what is not > "illegitimate" and "abuse". I reckon if/when this proposal has gone through (either confirmed or rejected), some sane solution to this whole thing has to be found ... as several people - even some nay-sayers - have said, the current proposal does not cover enough bases to discourage or prevent policy abuse. I'm sure that - as it has a direct impact on the business of both IP-brokers and wannabe-profiteers - it will face even stronger opposition by several people, but most likely no substantial arguments (as we have already seen these last couple days - after all, saying "it will cut in my personal profit" won't be a valid argument against the policy to knowingly cut into profits of policy-abusers in order to allow late entries into the ISP market some affordable set of IPv4 addresses). Without really thinking about all possibilities, I would imagine there are certain reasons for or against the transfer of IPs, though some wording and "way of proof" would have to be found that be used to decide whether a transfer was permitted or not ... >From the top of my head, for a transfer, certain situations come to mind: * merger/acquisition of company (can be proved through official papers/registration information) * is there actually any other justifiable reason? Personally, I would see certain use cases where a transfer is not necessary for any technical/organizational reasons: (which may even weigh stronger than e.g. the merger/acquisition argument) * shutdown of an ISP or company, where loss of IP usage would not impact customers (current use is terminated, IPs are no longer announced) * IPs were never (publicly?) used or only intermittently announced (how could actual use be documented apart from just an announcement? Would an announcement on the Internet be sufficient?), or have been unused for a certain amount of time (3 months?) Due to the fact that IP addresses (especially PAs assigned to an LIR) are not "owned" by the LIR (in part documented by the yearly bill for the resource) IPs should not count as an asset with monetary value, thus allowing the RIR to collect them if policy requirements aren't met. Possibly: Requirement to announce and use IPs from last-/8 within 3 months of assignment, otherwise the non-transferal-duration would be extended by 1 year *putting on flame-resistant armor* -garry
- Previous message (by thread): [address-policy-wg] [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)
- Next message (by thread): [address-policy-wg] Future of Re: [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]