Hi Sascha,
please see inline:
On 4/25/17 7:10 PM, Sascha Luck [ml] wrote:
All,
On Tue, Apr 25, 2017 at 02:39:43PM +0200, Marco Schmidt wrote:
A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR
Legacy updates" is now available for discussion.
The goal of this proposal is to require the RIPE NCC to publish all
changes to the holdership of legacy resources in the existing
transfer statistics.
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2017-01
It would be nice if the initial email for a new proposal could
contain the textual changes to policy documents. It would make it
infintely easier to comment inline on the changed sections.
additions to the current policy documents in *bold*:
RIPE Resource Transfer Policies (currently ripe-682):
* Whether it was a transfer according to this policy, a transfer due
to changes to an organisation's business structure (such as a merger
or acquisition) *or a change in the RIPE Database to the
organisation holding a Legacy Internet Resource.*
RIPE NCC Services to Legacy Internet Resource Holders (currently ripe-674):
* *Transfer services as per****RIPE Resource Transfer Policies
<http://www.ripe.net/publications/docs/transfer-policies>**. Any
change in the RIPE Database updating the organisation holding the
Legacy Internet Resource can only be finalised once the RIPE NCC has
received and verified a written request signed by authorised
representatives of both the current holder and the new holder.*
4.0 Transfer Statistics
[...]
This list will contain information about approved changes. The
following information will be published:
[...]
Whether it was a transfer according to this policy, a transfer
due to changes to an organisation's business structure (such as a
merger or acquisition) or a change in the RIPE Database to the
organisation holding a Legacy Internet Resource.
Since when has the RIPE NCC a mandate to "approve" changes in
legacy objects? (Except perhaps where a contractual relationship
exists)
It does not. And this policy proposal does not intend to give more
'power' to the RIPE NCC over the Legacy holders.
What it will do is, for 'transfers' of Legacy space where both the old
and the new holder want to have it verified by the RIPE NCC, both
parties will need to sign a document where parties authorised to sign
will confirm the change of the legacy holder (basically, a transfer).
Transfers where the legacy holders do not want the RIPE NCC to
acknowledge the change in the legacy holder will be marked as such. This
policy proposal does not require both parties to sign such a document in
order to complete a transfer.
RIPE NCC Services to Legacy Internet Resource Holders
[...]
1.1 Definitions
[...]
Registry services
[...]
Transfer services as per RIPE Resource Transfer Policies. Any
change in the RIPE Database updating the organisation holding the
Legacy Internet Resource can only be finalised once the RIPE NCC
has received and verified a written request signed by authorised
representatives of both the current holder and the new holder.
Since when does the RIPE NCC have the mandate to impose such a
process on legacy resource holders?
This is what the policy proposal will add. It currently does not have a
mandate and the mandate will be given once this proposal becomes policy.
It only requires the RIPE NCC to verify that authorised representatives
sign a template where they accept and acknowledge the change of the
legacy block and the fact that a new legacy holder now holds this block.
If this policy proposal is approved and if the two organizations do not
want to sign such a document, the RIPE NCC will mark the updated legacy
resource in some way (maybe a remarks attribute) signaling that the IP
block has been updated and the RIPE NCC has not been notified of such
change. Therefore, the transfer is not 'finalised'.
Rationale
a. Arguments supporting the proposal
Providing complete statistics about IPv4 transfers and updates to
the holdership of legacy resources would clearly show the whole
picture of a young, unpredictable and volatile transfer market.
We currently see only partial information and it is difficult to
understand the real dimensions of the size and number of IPv4
transfers.
Over the past few years, this update has been requested by
everyone analysing the IPv4 marketplace and presenting at RIPE,
ARIN or APNIC conferences. The RIPE NCC already publishes
statistics on inter-RIR transfers and adding this last bit
(updates on who holds legacy resources) would be consistent with
the community's requests around transparency and consistency.
Read this as:
"This is the latest attempt to instrumentalise the
(membership-funded) RIPE NCC as a free business intelligence
resource for IPv4 address brokers."
Please elaborate how this would be a business intelligence for the IPv4
address brokers.
I represent an IPv4 address broker and can not see how this is going to
help my business.
I am also a RIPE NCC member and I pay my yearly membership, just as you do.
I can already see who is a legacy resource holder and I can already see
the changes in the RIPE Database; how would publishing the statistics of
IP transfers of legacy resources be of any help to my company?
In order to identify all legacy changes, a confirmation will be
sent to the RIPE NCC to finalise the process (currently this is
only checked for legacy resources that have a contractual
relationship with the RIPE NCC or sponsoring LIR). This
verification requirement does not impact the transfer of legacy
resources or the updates in the RIPE Database. It only adds an
additional step to increase the registration quality.
What makes you think imposing a bureaucratic requirement on
legacy holders out of the blue will not be resisted?
Why would someone resist it? It would add a security layer to the Buyer
by having the RIPE NCC verify that the IP block transferred has the
approval of the management of the original legacy holder.
It would also prevent hijackers (that may have gotten their hands on the
password of a maintainer of a legacy resource) from transferring IP
blocks they do not hold.
I remember
the discussions around formalising the legacy resource
relationship with the NCC and how the voluntary nature of any
such relationship was emphasized in order to get any sort of
consensus.
And, based on those discussions, this policy proposal does not require
the RIPE NCC to approve the transfer of a Legacy. Where both parties
request it by signing a transfer template, the RIPE NCC will confirm the
transfer.
In short, this proposal has the potential to:
- benefit the few at a cost to all members,
what will be that cost?
- sour relations with legacy resource holders,
how so?
- have a deletorious effect on registry quality where resource
holders do not wish to submit to a "verification" process,
they can still update the object, the RIPE NCC will only mark the update
as not yet verified.
The current situation already has a negative impact on the registry and
this policy proposal could fix it when both the old and the new legacy
holder will sign a transfer template and the RIPE NCC verifies the
authenticity of the signatories.
and therefore I, strenuously, object to this proposal (for
whatever that may be worth)
Even after the comments above, do you still object to the proposal?
Is there any method to achieve the end goal (publishing complete
transfer statistics) you would not object to?
rgds,
Sascha Luck
Kind regards,
Elvis
--
Elvis Daniel Velea
V4Escrow LLC
Chief Executive Officer
E-mail: [email protected]
Mobile: +1 (702) 970 0921
