<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <font size="+1"><tt>Dear Aleksi<br>
        <br>
        Thank you for your comments. I have replied in more detail in
        line below.<br>
        <br>
        Sorry for another long email, but there really are a lot more
        discussion points about abuse-c implementation than you
        think...so I highlighted the important bit which was the last
        paragraph below and moved it to here:<br>
      </tt></font><font size="+1"><tt><br>
        ****** The important bit *******<br>
        I may be going off at a tangent here, but I am trying to explain
        some of the background thinking as to why we implemented the
        abuse-c the way we did. We are trying to centralise the
        'management' data in the database and link it to the
        organisation and allow it to be inherited by other data. In the
        long term this should reduce the amount of the management data
        in the database. We don't want to go the other way and increase
        the amount of duplicated management data. Right now the database
        has far more management data in it than operational data. With
        proper use of inheritance and better management tools, there
        could be a massive reduction of this management data.<br>
        *****************************<br>
        <br>
        Regards<br>
        Denis Walker<br>
        Business Analyst<br>
        RIPE NCC Database Team<br>
        <br>
      </tt></font>
    <div class="moz-cite-prefix">On 07/05/2014 03:27, Aleksi Suhonen
      wrote:<br>
    </div>
    <blockquote cite="mid:53698BFD.3040002@ssd.axu.tm" type="cite">Hello,
      <br>
      <br>
      On 05/06/2014 06:01 PM, Denis Walker wrote:
      <br>
      <blockquote type="cite">Two issues have been identified that are
        seen to be difficult to handle
        <br>
        with the current model - partitioned subnets within one
        organisation and
        <br>
        adding abuse contacts to more specifics for End Users. The RIPE
        NCC has
        <br>
        considered these two issues and found what we believe to be
        practical
        <br>
        solutions, available within the current model.
        <br>
      </blockquote>
      <br>
      <blockquote type="cite">More information about these solutions and
        the implementation of
        <br>
        "abuse-c:" is available on RIPE Labs:
        <br>
<a class="moz-txt-link-freetext" href="https://labs.ripe.net/Members/denis/suggestions-for-improving-abuse-handling">https://labs.ripe.net/Members/denis/suggestions-for-improving-abuse-handling</a>
        <br>
      </blockquote>
      <br>
      I find this suggestion clumsy. It adds hard to parse extraneous
      information to simple objects. The organization object for a very
      large organization would become unmanageable and unintelligible
      quickly.
      <br>
    </blockquote>
    <br>
    Who do you believe is going to parse this object for this
    information? The RIPE NCC already has an Abuse Finder tool which can
    be accessed directly or via RIPEstat. As I said in the last
    paragraph of my article, people should start to move away from the
    old fashioned idea of digging directly into the RIPE Database
    themselves to find data, parse it and interpret it. If you need
    information the RIPE NCC will provide web tools and API calls to
    supply that information. We will  do all the digging, parsing and
    interpretation for you.<br>
    <br>
    We will also provide tools for maintainers of the data to provide
    you with a neat overview of who handles abuse throughout your whole
    network. We also proposed a wizard for adding and removing abuse
    contact details for your End Users. We can also add functionality to
    the overview page to add/remove further abuse details for your
    subnets.<br>
    <br>
    In the end it should not matter to you where this data is stored in
    the database. You deal in information, we deal in data storage and
    retrieval. To be honest we don't even need to put this data into any
    object. We can just store it as meta data associated with your
    organisation. As long as we provide you with tools to view and
    manage the information and for the public to find what they
    need....leave the storage to us.<br>
    <br>
    <blockquote cite="mid:53698BFD.3040002@ssd.axu.tm" type="cite">
      <br>
      I would much rather like to see a new inetnum and inet6num object
      status "INFORMATIONAL" that only requires authorization of the
      immediately larger enclosing inet(6)num object, and doesn't
      represent an assignment or allocation at all. Such objects can
      then be used to redirect technical, administrative and abuse
      contacts to the proper places, as well as present their own
      remarks and descriptions.
      <br>
    </blockquote>
    <br>
    I believe this is going in completely the wrong direction. This
    means creating more 'management' objects and replicating even more
    data all over the database. We already have 3.8 million INETNUM
    objects all with a mandatory admin-c and tech-c. That is 7.6M bits
    of replicated data! We only have 10k members. These members manage
    the majority of the end user resources as well as their own
    networks. What this database is really missing is inheritance. Most
    of this management information could be stored with your
    organisation, as the abuse-c is, and then inherited by most of the
    operational data.<br>
    <br>
    Just did some quick stats...we have 7.4M objects in the database and
    1.96M unique nic-hdls used in the admin-c, tech-c and zone-c
    attributes. We know some large users have a business model to create
    a nic-hdl for every customer. They certainly account for a few
    hundred thousand of these nic-hdls. So probably we have about 1.5M
    nic-hdls replicated over 7.4 million objects. That is a lot of data
    duplication.<br>
    <br>
    <blockquote cite="mid:53698BFD.3040002@ssd.axu.tm" type="cite">
      <br>
      This solution would cover PI, PA and all other styles of address
      blocks equally well. I know this has been suggested many times
      before, but I still think it would be a much more elegant solution
      to this problem.
      <br>
      <br>
      Yours,
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>