<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><font size="+1"><tt>Hi Ronald</tt></font></p>
    <p><font size="+1"><tt>I have added some more comments below about
          this specific ROUTE object you gave as an example.<br>
        </tt></font></p>
    <div class="moz-cite-prefix">On 21/11/2016 01:12, Rene Wilhelm
      wrote:<br>
    </div>
    <blockquote cite="mid:1516ae60-4249-ac9d-05e5-dbce3845544b@ripe.net"
      type="cite">Hi,
      <br>
      <br>
      On 11/20/16 10:05 PM, Ronald F. Guilmette wrote:
      <br>
      <blockquote type="cite">[...]
        <br>
        I have just now been trying to apply those options to a single
        route
        <br>
        object and so far I am not having any success at all.� Are those
        options
        <br>
        supposed to work for individual route objects?� If so, then
        obviously
        <br>
        I'm just doing it wrong, and getting only errors back.� If you
        could
        <br>
        show me the correct syntax for using these options on individual
        route
        <br>
        objects, I'd be most greatful.� For example, if you could show
        me how
        <br>
        to view the different verssions of the 36.116.128.0/17 route
        object,
        <br>
        that would be great.
        <br>
      </blockquote>
      <br>
      To query version history for route objects you need to include the
      <br>
      origin AS number in the query. Together with the prefix that
      identifies
      <br>
      a single route object in the database:
      <br>
      <br>
      whois -h whois.ripe.net ' --list-versions 36.116.128.0/17AS52523'
      <br>
      [...]
      <br>
      <br>
      rev#� Date������������� Op.
      <br>
      <br>
      1���� 2016-03-12 20:11� ADD/UPD
      <br>
      2���� 2016-04-25 15:15� ADD/UPD
      <br>
      <br>
      <br>
      whois --show-version 1 36.116.128.0/17AS52523
      <br>
      <br>
      % Version 1 of object "36.116.128.0/17AS52523"
      <br>
      % This version was a UPDATE operation on 2016-03-12 20:11
      <br>
      % You can use "--list-versions" to get a list of versions for an
      object.
      <br>
      <br>
      route:��������� 36.116.128.0/17
      <br>
      descr:��������� EU route
      <br>
      origin:�������� AS52523
      <br>
      mnt-by:�������� RIPE-NCC-RPSL-MNT
      <br>
      created:������� 2016-03-12T19:11:19Z
      <br>
      last-modified:� 2016-03-12T19:11:19Z
      <br>
      source:�������� RIPE
      <br>
      <br>
      <br>
      So this is one of those cases which Denis described: the insecure
      maintainer
      <br>
      RIPE-NCC-RPSL-MNT was replaced by RIPE-NCC-LOCKED-MNT on
      2016-04-25.
      <br>
      <br>
      <blockquote type="cite">(It would be very helpful to be able to
        know who
        <br>
        or what was supposedly maintaining that object, and others of
        interest
        <br>
        to me, prior to the time when they were set to
        RIPE-NCC-LOCKED-MNT.
        <br>
      </blockquote>
      <br>
      some quick scripting suggests the bulk of the (ipv4) route objects
      which
      <br>
      have mnt-by RIPE-NCC-LOCKED-MNT today only ever had mnt-by
      RIPE-NCC-RPSL-MNT
      <br>
      before.
      <br>
      <br>
      12 route objects have been locked more than a decade ago, due to
      <br>
      deprecation of the NONE authentication scheme. For example:
      <br>
      <br>
      route:��������� 62.135.0.0/18
      <br>
      descr:��������� LINKdotNET Route
      <br>
      origin:�������� AS24863
      <br>
      mnt-by:�������� RIPE-NCC-LOCKED-MNT
      <br>
      remarks:������� Maintainer RIPE-NCC-NONE-MNT removed and object
      <br>
      remarks:������� LOCKED by the RIPE NCC due to
      <br>
      remarks:������� deprecation of the NONE authentication scheme.
      <br>
      remarks:������� Please visit the following URL to unlock this
      object
      <br>
      remarks: <a class="moz-txt-link-freetext" href="http://www.ripe.net/db/none-deprecation-042004.html">http://www.ripe.net/db/none-deprecation-042004.html</a>
      <br>
      created:������� 2002-07-30T17:02:26Z
      <br>
      last-modified:� 2004-04-30T06:14:23Z
      <br>
      source:�������� RIPE
      <br>
      <br>
      -- Rene
      <br>
    </blockquote>
    <br>
    If you query this prefix using webupdates and select '
    <meta http-equiv="content-type" content="text/html;
      charset=windows-1252">
    Search resource objects in all available databases' you will see the
    address range is from APNIC region<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=windows-1252">
    ��� inetnum:�������� 36.96.0.0 - 36.127.255.255<br>
    ��� netname:�������� CHINANET-ZJ<br>
    ��� descr:���������� CHINANET Zhejiang province network<br>
    ��� descr:���������� Data Communication Division<br>
    ��� descr:���������� China Telecom<br>
    ��� country:�������� CN<br>
    ��� admin-c:�������� DUMY-RIPE<br>
    ��� tech-c:��������� DUMY-RIPE<br>
    ��� notify:��������� <a class="moz-txt-link-abbreviated" href="mailto:antispam@dcb.hz.zj.cn">antispam@dcb.hz.zj.cn</a><br>
    ��� mnt-by:��������� APNIC-HM<br>
    ��� mnt-lower:������ MAINT-CHINANET-ZJ<br>
    ��� mnt-routes:����� MAINT-CHINANET-ZJ<br>
    ��� mnt-irt:�������� IRT-CHINANET-ZJ<br>
    ��� remarks:��������
    --------------------------------------------------------<br>
    ��� remarks:�������� To report network abuse, please contact mnt-irt<br>
    ��� remarks:�������� For troubleshooting, please contact tech-c and
    admin-c<br>
    ��� remarks:�������� Report invalid contact via
    <a class="moz-txt-link-abbreviated" href="http://www.apnic.net/invalidcontact">www.apnic.net/invalidcontact</a><br>
    ��� remarks:��������
    --------------------------------------------------------<br>
    ��� status:��������� ALLOCATED PORTABLE<br>
    ��� source:��������� APNIC-GRS<br>
    ��� remarks:�������� ****************************<br>
    ��� remarks:�������� * THIS OBJECT IS MODIFIED<br>
    ��� remarks:�������� * Please note that all data that is generally
    regarded as personal<br>
    ��� remarks:�������� * data has been removed from this object.<br>
    ��� remarks:�������� * To view the original object, please query the
    APNIC Database at:<br>
    ��� remarks:�������� * <a class="moz-txt-link-freetext" href="http://www.apnic.net/">http://www.apnic.net/</a><br>
    ��� remarks:�������� ****************************<br>
    <br>
    Doing the same for the ASN you see it is from LACNIC region:<br>
    <br>
    ��� aut-num:�������� AS52523<br>
    ��� descr:���������� COMPANHIA PAULISTA DE FORCA E LUZ<br>
    ��� created:�������� 20130521<br>
    ��� source:��������� LACNIC-GRS<br>
    ��� remarks:�������� ****************************<br>
    ��� remarks:�������� * THIS OBJECT IS MODIFIED<br>
    ��� remarks:�������� * Please note that all data that is generally
    regarded as personal<br>
    ��� remarks:�������� * data has been removed from this object.<br>
    ��� remarks:�������� * To view the original object, please query the
    LACNIC Database at:<br>
    ��� remarks:�������� * <a class="moz-txt-link-freetext" href="http://www.lacnic.net/">http://www.lacnic.net/</a><br>
    ��� remarks:�������� ****************************<br>
    <br>
    <br>
    This is what we refer to as an 'out of region' ROUTE object. This is
    one of the more extreme cases where both the prefix and ASN are
    outside the RIPE region. But the RIPE Database allows creation of
    such objects. Currently there is no authorisation done by the real
    resource holders and no notifications are sent to them that this
    object has been created in the RIPE Database. The resource holders
    in APNIC and LACNIC regions may not know this ROUTE object exists.
    Anyone can create such an object.<br>
    <br>
    This issue has been discussed at several recent RIPE Meetings but no
    consensus has been reached on how to move forward. But as you point
    out, there is an added complication now with some of these objects
    being locked. This was not part of the previous discussion on the
    subject. So no one is maintaining these objects, no one can delete
    them and maybe no one wants it to be there. And as you point out
    below, some people may give this (rogue) object credibility because
    it exists. Whoever created this object is unlikely to ask the RIPE
    NCC to unlock it as they may not have any valid reason for it being
    there. So this object is stuck in limbo... Perhaps if one of the
    resource holders asks the RIPE NCC to delete it they will do, but
    someone has to tell the resource holders it exists.<br>
    <br>
    cheers<br>
    denis<br>
    <br>
    <blockquote cite="mid:1516ae60-4249-ac9d-05e5-dbce3845544b@ripe.net"
      type="cite">
      <blockquote type="cite">
        <br>
        Anyway, here is my concern... I have just been having an email
        conversation
        <br>
        with one provider in the RIPE region.� I can summarize the
        conversation
        <br>
        as follows:
        <br>
        <br>
        ������ ME:� You should not be allowing your peer/customer to
        announce
        <br>
        ����������� route A.B.C.D/nn.
        <br>
        <br>
        ������ HIM:� We filter by using the RIPE route registry.� There
        is a route
        <br>
        ������������ object in the RIPE data base that says that our
        peer/customer
        <br>
        ������������ can announce A.B.C.D/nn.
        <br>
        <br>
        I am concerned that in some cases the RIPE data base contains
        some route
        <br>
        objects that should not have been allowed in there in the first
        place,
        <br>
        and that to make matters worse, some of these now have mnt-by
        set to
        <br>
        RIPE-NCC-LOCKED-MNT which has _two_ possible ill effects, i.e.
        (1) it
        <br>
        hides the identity of the party who put the route object into
        the data
        <br>
        base in the first place and (2) it in effect freezes in place
        some
        <br>
        improper route objects that should never have gotten into the
        data base
        <br>
        in the first place.� And in some cases, for some of the
        providers who
        <br>
        may be checking the routes that they either originate or pass
        against
        <br>
        the RIPE data base, this may have the effect of permanently
        legitimizing
        <br>
        bogus and perhaps even illicit routes.
        <br>
        <br>
        I would like to know if anyone other than me thinks this might
        be an
        <br>
        issue.� I mean how will the bogus route objects ever be removed
        if they
        <br>
        are set to RIPE-NCC-LOCKED-MNT?
        <br>
        <br>
        <br>
      </blockquote>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>