<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hi Sascha,</p>
    <p>please see inline:<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 4/25/17 7:10 PM, Sascha Luck [ml]
      wrote:<br>
    </div>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">All,
      <br>
      <br>
      On Tue, Apr 25, 2017 at 02:39:43PM +0200, Marco Schmidt wrote:
      <br>
      <blockquote type="cite">
        <br>
        A new RIPE Policy proposal, 2017-01, "Publish statistics on
        Intra-RIR Legacy updates" is now available for discussion.
        <br>
        <br>
        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.
        <br>
        <br>
        You can find the full proposal at:
        <br>
        <a class="moz-txt-link-freetext" href="https://www.ripe.net/participate/policies/proposals/2017-01">https://www.ripe.net/participate/policies/proposals/2017-01</a>
        <br>
      </blockquote>
      <br>
      It would be nice if the initial email for a new proposal could
      <br>
      contain the textual changes to policy documents. It would make it
      <br>
      infintely easier to comment inline on the changed sections.
      <br>
    </blockquote>
    additions to the current policy documents in <b>bold</b>:<br>
    <br>
    RIPE Resource Transfer Policies (currently ripe-682):<br>
    <br>
    <ul style="box-sizing: border-box; margin: 0px 0px 12px; padding:
      0px 0px 0px 20px; list-style-type: disc; color: rgb(51, 51, 51);
      font-family: 'Open Sans', Helvetica, Arial, sans-serif; font-size:
      14.300000190734863px; font-style: normal; font-variant-caps:
      normal; font-weight: normal; letter-spacing: normal; orphans:
      auto; text-align: start; text-indent: 0px; text-transform: none;
      white-space: normal; widows: auto; word-spacing: 0px;
      -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">
      <li style="box-sizing: border-box; max-width: 700px; display:
        list-item;">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) <b>or a change in
          the RIPE Database to the organisation holding a Legacy
          Internet Resource.</b></li>
    </ul>
    RIPE NCC Services to Legacy Internet Resource Holders (currently
    ripe-674):<br>
    <br>
    <ul style="box-sizing: border-box; margin: 0px 0px 12px; padding:
      0px 0px 0px 20px; list-style-type: disc; color: rgb(51, 51, 51);
      font-family: 'Open Sans', Helvetica, Arial, sans-serif; font-size:
      14.300000190734863px; font-style: normal; font-variant-caps:
      normal; font-weight: normal; letter-spacing: normal; orphans:
      auto; text-align: start; text-indent: 0px; text-transform: none;
      white-space: normal; widows: auto; word-spacing: 0px;
      -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">
      <li style="box-sizing: border-box; max-width: 700px; display:
        list-item;"><b>Transfer services as per</b><b><span
            class="Apple-converted-space">�</span></b><b><a
            href="http://www.ripe.net/publications/docs/transfer-policies"
            data-linktype="external"
            data-val="http://www.ripe.net/publications/docs/transfer-policies"
            style="box-sizing: border-box; color: rgb(42, 100, 150);
            text-decoration: none; background-position: 0px 0px;
            background-repeat: initial initial;">RIPE Resource Transfer
            Policies</a></b><b>. 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.</b></li>
    </ul>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">
      <br>
      <blockquote type="cite">4.0 Transfer Statistics
        <br>
      </blockquote>
      [...]
      <br>
      <blockquote type="cite">This list will contain information about
        approved changes. The
        <br>
        following information will be published:
        <br>
      </blockquote>
      [...]
      <br>
      <blockquote type="cite">Whether it was a transfer according to
        this policy, a transfer
        <br>
        due to changes to an organisation's business structure (such as
        a
        <br>
        merger or acquisition) or a change in the RIPE Database to the
        <br>
        organisation holding a Legacy Internet Resource.
        <br>
      </blockquote>
      <br>
      Since when has the RIPE NCC a mandate to "approve" changes in
      <br>
      legacy objects? (Except perhaps where a contractual relationship
      <br>
      exists)
      <br>
    </blockquote>
    It does not. And this policy proposal does not intend to give more
    'power' to the RIPE NCC over the Legacy holders.<br>
    <br>
    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). <br>
    <br>
    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.<br>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">
      <br>
      <blockquote type="cite">RIPE NCC Services to Legacy Internet
        Resource Holders
        <br>
      </blockquote>
      [...]
      <br>
      <blockquote type="cite">1.1 Definitions
        <br>
      </blockquote>
      [...]
      <br>
      <blockquote type="cite">Registry services
        <br>
      </blockquote>
      [...]
      <br>
      <blockquote type="cite">Transfer services as per RIPE Resource
        Transfer Policies. Any
        <br>
        change in the RIPE Database updating the organisation holding
        the
        <br>
        Legacy Internet Resource can only be finalised once the RIPE NCC
        <br>
        has received and verified a written request signed by authorised
        <br>
        representatives of both the current holder and the new holder.
        <br>
      </blockquote>
      <br>
      Since when does the RIPE NCC have the mandate to impose such a
      <br>
      process on legacy resource holders? <br>
    </blockquote>
    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.<br>
    <br>
    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.<br>
    <br>
    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'.<br>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">
      <blockquote type="cite">Rationale
        <br>
      </blockquote>
      <br>
      <blockquote type="cite">a. Arguments supporting the proposal
        <br>
      </blockquote>
      <br>
      <blockquote type="cite">Providing complete statistics about IPv4
        transfers and updates to
        <br>
        the holdership of legacy resources would clearly show the whole
        <br>
        picture of a young, unpredictable and volatile transfer market.
        <br>
        We currently see only partial information and it is difficult to
        <br>
        understand the real dimensions of the size and number of IPv4
        <br>
        transfers.
        <br>
      </blockquote>
      <br>
      <blockquote type="cite">Over the past few years, this update has
        been requested by
        <br>
        everyone analysing the IPv4 marketplace and presenting at RIPE,
        <br>
        ARIN or APNIC conferences. The RIPE NCC already publishes
        <br>
        statistics on inter-RIR transfers and adding this last bit
        <br>
        (updates on who holds legacy resources) would be consistent with
        <br>
        the community's requests around transparency and consistency.
        <br>
      </blockquote>
      <br>
      Read this as:
      <br>
      "This is the latest attempt to instrumentalise the
      <br>
      (membership-funded) RIPE NCC as a free business intelligence
      <br>
      resource for IPv4 address brokers."� <br>
    </blockquote>
    Please elaborate how this would be a business intelligence for the
    IPv4 address brokers. <br>
    I represent an IPv4 address broker and can not see how this is going
    to help my business. <br>
    I am also a RIPE NCC member and I pay my yearly membership, just as
    you do.<br>
    <br>
    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?<br>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">
      <blockquote type="cite">In order to identify all legacy changes, a
        confirmation will be
        <br>
        sent to the RIPE NCC to finalise the process (currently this is
        <br>
        only checked for legacy resources that have a contractual
        <br>
        relationship with the RIPE NCC or sponsoring LIR). This
        <br>
        verification requirement does not impact the transfer of legacy
        <br>
        resources or the updates in the RIPE Database. It only adds an
        <br>
        additional step to increase the registration quality.
        <br>
      </blockquote>
      <br>
      What makes you think imposing a bureaucratic requirement on
      <br>
      legacy holders out of the blue will not be resisted? </blockquote>
    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.<br>
    <br>
    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.<br>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">I remember
      <br>
      the discussions around formalising the legacy resource
      <br>
      relationship with the NCC and how the voluntary nature of any
      <br>
      such relationship was emphasized in order to get any sort of
      <br>
      consensus. <br>
    </blockquote>
    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.<br>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">In short, this proposal has the potential to:
      <br>
      <br>
      - benefit the few at a cost to all members,
      <br>
    </blockquote>
    what will be that cost? <br>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">- sour relations with legacy resource holders,
      <br>
    </blockquote>
    how so?<br>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">- have a deletorious effect on registry quality where
      resource
      <br>
      �holders do not wish to submit to a "verification" process,
      <br>
    </blockquote>
    they can still update the object, the RIPE NCC will only mark the
    update as not yet verified.<br>
    <br>
    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.<br>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">
      <br>
      and therefore I, strenuously, object to this proposal (for
      <br>
      whatever that may be worth)
      <br>
    </blockquote>
    Even after the comments above, do you still object to the proposal?<br>
    <br>
    Is there any method to achieve the end goal (publishing complete
    transfer statistics) you would not object to?<br>
    <blockquote cite="mid:20170425161057.GZ93886@cilantro.c4inet.net"
      type="cite">
      <br>
      rgds,
      <br>
      Sascha Luck
      <br>
      <br>
      <br>
      <br>
    </blockquote>
    Kind regards,<br>
    Elvis<br>
    <pre class="moz-signature" cols="72">-- 
Elvis Daniel Velea
V4Escrow LLC
Chief Executive Officer
E-mail: <a class="moz-txt-link-abbreviated" href="mailto:elvis@v4escrow.net">elvis@v4escrow.net</a>
Mobile: +1 (702) 970 0921</pre>
  </body>
</html>