<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font size="+1"><tt>Hi Tim<br>
        <br>
        Thanks for the reply. I will give a brief comment, although I
        can give more details if necessary.<br>
        <br>
        According to the policy ripe-563 "abuse-c:" is mandatory on all
        internet resources, including non-LIR assignments. Legacy
        resource holders are not required to follow all RIPE policies
        and do not need to provide it. However, if they choose to supply
        this information they must use the methods available within the
        RIPE Database.<br>
        <br>
        The impact analysis on this policy<br>
        <a class="moz-txt-link-freetext" href="https://www.ripe.net/participate/policies/proposals/2011-06">https://www.ripe.net/participate/policies/proposals/2011-06</a><br>
        covered the cleanup of "abuse-mailbox:" from other objects by
        converting them into "remarks:".<br>
        <br>
        But it does no harm to discuss it again and ask the community to
        reaffirm the cleanup process.<br>
        <br>
        cheers<br>
        Denis Walker<br>
        Independent Netizen<br>
        <br>
      </tt></font><br>
    <div class="moz-cite-prefix">On 06/05/2015 17:18, Tim Bruijnzeels
      wrote:<br>
    </div>
    <blockquote cite="mid:FE10D084-3F77-43D4-9DC5-8536C6A9A8BF@ripe.net"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=us-ascii">
      Dear colleagues,
      <div class=""><br class="">
        <div class="">
          <blockquote type="cite" class="">On 05 May 2015, at 15:59,
            denis walker <<a moz-do-not-send="true"
              href="mailto:ripedenis@yahoo.co.uk" class="">ripedenis@yahoo.co.uk</a>>
            wrote:</blockquote>
          <div class="">
            <blockquote type="cite" class=""><br class="">
              When the original implementation plan was put forward for
              "abuse-c:", the time line (if I remember correctly) was:<br
                class="">
              -allowing 6 months to deploy to all members allocations<br
                class="">
              -then 12 months to deploy to all independent resources<br
                class="">
              -then do a cleanup<br class="">
            </blockquote>
            <br class="">
          </div>
          <div class="">I believe you are referring to this:</div>
          <div class=""><a moz-do-not-send="true"
href="https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06"
              class="">https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-2011-06</a></div>
          <div class=""><br class="">
          </div>
          <div class="">
            <blockquote type="cite" class="">Can the RIPE NCC confirm
              that all resources now have an "abuse-c:"?</blockquote>
          </div>
          <div class=""><br class="">
          </div>
          <div class="">No, there are still organisations without
            abuse-c associated with resources.</div>
          <div class=""><br class="">
          </div>
          <div class="">1 = Some LIRs are still missing abuse-c</div>
          <div class=""><br class="">
          </div>
          <div class="">Once the abuse-c has been set up for an
            organisation it cannot be removed, although it can be
            modified. However, "abuse-c:" still needs to be set for some
            LIRs created after phase-1 was completed. This is due to the
            fact that until recently new LIRs needed to create their own
            maintainer, abuse-c role object manually after membership
            activation. So new cases of LIRs that do not have an abuse-c
            set up were added every day.</div>
          <div class=""><br class="">
          </div>
          <div class="">We updated the member activation process
            recently and now a maintainer and abuse-c role are created
            as part of the activation process.</div>
          <div class=""><br class="">
          </div>
          <div class="">So, going forward we can now contact the
            remaining LIRs to set the abuse-c, and be sure that no new
            cases are created. We have not done this yet, because we
            were focusing on implementing the phase 1 and 2 of
            deprecating changed first.</div>
          <div class=""><br class="">
          </div>
          <div class="">2 = Not all organisations have an abuse-c</div>
          <div class=""><br class="">
          </div>
          <div class="">The RIPE NCC only has a policy mandate to
            enforce abuse-c for organisations associated with resources
            allocated or assigned through the RIPE NCC. I.e.
            organisations holding legacy resources or assignments made
            by LIRs are not covered.</div>
          <div class=""><br class="">
          </div>
          <div class=""><br class="">
          </div>
          <div class="">
            <blockquote type="cite" class="">The idea of "abuse-c:" was
              to create one single place/way of documenting abuse
              contact details. So far all that has been achieved is to
              add a�fourth way to document it. All the old ways
              ("abuse-mailbox:" in 5 object types, IRT and remarks) are
              still littered throughout the database.<br class="">
            </blockquote>
          </div>
          <div class=""><br class="">
          </div>
          <div class="">A schema change like this would need to be
            discussed in the database working group, and can only be
            done in case "abuse-c:" can be made mandatory for all
            organisations - and this would also have to be discussed
            there.</div>
          <div class=""><br class="">
          </div>
          <div class="">From a technical point of view this change is
            not necessarily difficult to implement, provided that
            missing abuse-c roles could be created using either the
            existing abuse-mailbox or email attribute on organisations -
            presumably the addresses people would turn to today in the
            absence of an explicit abuse-c. So, in a way this change
            should not have a big semantic impact. Consistency would
            help to reduce complexity in documentation and business
            rules. It would also make it easier when assigning resources
            to new non-LIR organisations - now we need to check whether
            abuse-c has been set, because it's not mandatory and we
            often find that this makes dealing with requests longer.</div>
          <div class=""><br class="">
          </div>
          <div class="">But that said, the above is only a partial
            picture of this, and this should in our view be discussed in
            the database working group. We can implement after consensus
            is called.</div>
          <div class=""><br class="">
          </div>
          <div class=""><br class="">
          </div>
          <div class=""><br class="">
          </div>
          <div class="">Kind regards,</div>
          <div class=""><br class="">
          </div>
          <div class="">Tim Bruijnzeels</div>
          <div class=""><br class="">
          </div>
          <div class="">Assistant Manager Software Engineering</div>
          <div class="">RIPE NCC</div>
          <div class=""><br class="">
          </div>
          <div class=""><br class="">
          </div>
          <div class=""><br class="">
          </div>
          <div class=""><br class="">
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>