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/[email protected]/
[policy-announce] [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
- Next message (by thread): [policy-announce] 2015-04 Discussion Period extended until 25 September 2015 (RIPE Resource Transfer Policies)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Erik Bais
erik at bais.name
Tue Sep 1 23:52:33 CEST 2015
Hi James, > Couple of questions/comments... > From 1.0 > Shouldn't the scope be explicit as to what is/isn't included It states what is included ... are you missing anything specific ? > From 2.1 > "Transfers can be on a permanent or non-permanent basis." > How is this going to be recorded and managed within the context of > reflecting it being a non-permanent transfer? That is taken directly from the current policy text and it is managed by the RIPE NCC. I must admit that I haven't seen non-permanent transfers myself (yet), so I would have to ask the NCC on how they are exposing that if at all publicly. The text itself isn't different to what there is already there. > From 2.2 > "assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs)" > Rather than "such as" this needs to be a definitive list of what is > classed as a restricted resource The part between the round brackets was put there as the current examples to what are the almost depleted resources. As IPv4 isn't completely depleted yet ( due to the final /8 policy ) and neither are 16-bit ASN's.. That implies that other resources like IPv6 or 32-bit ASN's are not restrictive by a 24 month transfer restriction as there is no logical requirement that we could find to put it in the policy. > From 3.1 > Again a list of conditions or references to policies that impose restrictions needed You mean other than what is currently in the proposed text ? Currently all resources that we have are possible to be transferred ... > From 4.0 > M&A process is mentioned, should there be other references to this? > Especially as M&A (as I understand it) allows 2.2 to be overridden An M&A is not a transfer ... a M&A is a change in a business where one company or service offering with assets/resources are going from one company to another company. That can be in the same company ( Look at companies like IBM or Philips or GE for instance that are splitting off services to a new business unit .. or buying competing companies and incorporating that into their own business / service..) Sometimes there are stocks being sold, however there are more ways of M&A's within today's business. Typical the goal of M&A's are not the (number) resources, but other services/assets/added value that would create the value ... And with a transfer, the goal is getting or selling the specified resource. Also the M&A is a business (operational) process.. and transfers are a policy. > General > - As this is about transfers should this also cover returning > resources to ripe NCC so all types of transfers be included The text is pretty clear imho on what it covers.. any number resource to and from the RIPE NCC service region ... Both TO and FROM the RIPE region ... > - broadly support the unification of transfer policy into a single > document, just things bits are missing or muddy I hope that we made a good start here :) Erik Bais
- Next message (by thread): [policy-announce] 2015-04 Discussion Period extended until 25 September 2015 (RIPE Resource Transfer Policies)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]