<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Piotr,<br>
    <br>
    We’re happy to outline some high-level approaches for how we might
    meet the requirements of the proposal. Please note that details of
    the actual implementation and potential limitations will need
    further study and will be covered in the impact analysis. We will
    seek guidance from the RIPE community on which particular approach
    it would like us to take — whether this ends up being a variation on
    one of the approaches mentioned below, or something different
    altogether. <br>
    <br>
    With this in mind, we would like to share the following information
    to support the WG’s discussion. <br>
    <br>
    The RIPE Database currently contains ~70,200 inetnum objects and
    ~700 aut-num objects with the status LEGACY. Of these, around 11,900
    have an organisation object referenced, with around 3,900 of these
    organisation objects having an abuse-c attribute in place. This
    means that around 17% of the resource objects have an organisation
    object and around 5.5% have a reference to an abuse contact.<br>
    <br>
    One possible approach could be to add the abuse-c attribute to
    existing organisation objects. This could be done in a similar way
    to how it was done for resources that were allocated or assigned by
    the RIPE NCC. Resources without an organisation object would not
    have an abuse contact. <br>
    <br>
    The mandatory database update that Erik mentioned could be another
    possible approach. Whenever a resource with the status LEGACY is
    updated, it must have a reference to an organisation object with the
    abuse-c attribute to perform this update. Resources that are not
    updated will not get an abuse contact. <br>
    <br>
    A third approach would add abuse-c references to all organisation
    objects held by legacy holders. The RIPE NCC would need to contact
    these holders of 67,000 objects, of which 59,000 have no
    organisation object. Taking into account our experience from
    implementing 2007-01, “Direct Internet Resource Assignments to End
    Users from the RIPE NCC”, we would expect a significant amount of
    manual work with this approach. The RIPE NCC is currently unable to
    enforce updates on legacy resources. <br>
    <br>
    We hope this helps with your discussion of the proposal. <br>
    <br>
    Kind regards<br>
    <br>
    <meta charset="utf-8">
    Marco Schmidt<br>
    Policy Development Officer<br>
    RIPE NCC<br>
    <br>
    On Thu, Jan 28, 2016 at 18:49:41 +0100, Piotr Strzyzewski wrote:<br>
    <br>
    <blockquote type="cite">On Thu, Jan 28, 2016 at 10:06:50AM +0100,
      Marco Schmidt wrote:<br>
      <br>
      Marco<br>
      <br>
      > A new RIPE Policy proposal, "Include Legacy Internet Resource
      Holders in <br>
      > the Abuse-c Policy", is now available for discussion.<br>
      ><br>
      > The goal of this proposal is to extend RIPE Document
      ripe-563, "Abuse <br>
      > Contact Management in the RIPE Database", to Legacy Internet
      Resource <br>
      > Holders.<br>
      ><br>
      > You can find the full proposal at:<br>
      ><br>
      >    
      <a class="moz-txt-link-freetext" href="https://www.ripe.net/participate/policies/proposals/2016-01">https://www.ripe.net/participate/policies/proposals/2016-01</a><br>
      ><br>
      > We encourage you to review this proposal and send your
      comments to<br>
      > <anti-abuse-wg at ripe.net> before 26 February 2016.<br>
      <br>
      Would you be so kind and publish possible approaches to deal with
      the<br>
      requirements of this proposal. It will be a benefit for the
      members of<br>
      this WG to see how NCC perceive this proposal.<br>
      <br>
      Thanks in advance,<br>
      Piotr<br>
      <br>
      -- <br>
      gucio -> Piotr Strzyżewski<br>
      E-mail: Piotr.Strzyzewski at polsl.pl</blockquote>
  </body>
</html>