2018-06 Discussion Phase (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up)
Dear colleagues, A new version of RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion. The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA. The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - Added reference to RFC 6811 - Clarification for Legacy Internet Resource Holders You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-06 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposers. At the end of the Discussion Phase, the proposers, with the agreement of the Working Group Chairs, decides how to proceed with the proposal. We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 20 June 2019. Kind regards, Marco Schmidt Policy Officer RIPE NCC
On May 22, 2019, at 7:28 AM, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
A new version of RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - Added reference to RFC 6811 - Clarification for Legacy Internet Resource Holders
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-06
As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposers.
At the end of the Discussion Phase, the proposers, with the agreement of the Working Group Chairs, decides how to proceed with the proposal.
We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 20 June 2019.
I support this proposal. We (Akamai) have invested considerable time in the past month to clean up our RIPE-NONAUTH objects (all the IPv4 ones are now gone). (IPv6 ones still need some cleanup, I should go check on the process here.. my goal was to have them all gone by RIPE78 but that did not happen). - Jared
On 22/05/2019 13:28, Marco Schmidt wrote:
We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 20 June 2019.
+1 -Christoffer
On Wed, May 22, 2019 at 2:29 PM Marco Schmidt <mschmidt@ripe.net> wrote:
We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 20 June 2019.
do you think the ROA check should be implemented also on addition of new records? I support this proposal
On Thu, May 23, 2019 at 15:05 Cosmin Lupu <cosmin@lupu.be> wrote:
On Wed, May 22, 2019 at 2:29 PM Marco Schmidt <mschmidt@ripe.net> wrote:
We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 20 June 2019.
do you think the ROA check should be implemented also on addition of new records?
Dear Cosmin, Nobody can create *new* records in the RIPE-NONAUTH database. It has been locked down when NWI-5 was completed. This checks/deletion proposal does *not* apply to the “RIPE” IRR source. Only in the “RIPE” database can new objects be created. When new objects are created in the “RIPE” database the creation of the object is verified against the owner of the IP resource, so these objects are not problematic. I understand we are juggling around quite some subtly different datasources, apologies for confusion. Kind regards, Job
I support this proposal
Hi WG, On 2019-05-22 13:29:10+02:00 routing-wg wrote: We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 20 June 2019. I strongly support this proposal. Although we don't have any, many of our customers have out-of-region objects in the db, which are often stale/duplicated/wrong. I welcome any steps that can be taken to clean this mess out without waiting around for operators to "do-the-right-thing". Cheers, Ben
I ageee on this proposal also. Den 23 maj 2019 15:35 skrev Ben Maddison via routing-wg <routing-wg@ripe.net>: Hi WG, On 2019-05-22 13:29:10+02:00 routing-wg wrote: We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 20 June 2019. I strongly support this proposal. Although we don't have any, many of our customers have out-of-region objects in the db, which are often stale/duplicated/wrong. I welcome any steps that can be taken to clean this mess out without waiting around for operators to "do-the-right-thing". Cheers, Ben
* Marco Schmidt <mschmidt@ripe.net> [2019-05-22 13:29]:
Dear colleagues,
A new version of RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
Sounds good to me. Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
* Marco Schmidt
A new version of RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
Eminently sensible. Supported. Tore
I was opposing the first version of this proposal, where conflicting objects were silently and instantly removed. The new version seems to resolve these concerns - and 7-day notification should be fine. But I'm not sure if all objects have optional 'notify' field (and a brief check showed that there are some without this field, I don't have exact numbers at the moment). If there is the technical opportunity I would suggest to also use notify field (and may be other contacts) from the related maintainer object. пт, 31 мая 2019 г. в 14:11, Tore Anderson <tore@fud.no>:
* Marco Schmidt
A new version of RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
Eminently sensible. Supported.
Tore
-- Best regards, Alexander Azimov
Hi, I think it would be good to look for contact details in the authoritative whois for the resources involved. E.g. RDAP provides a generic way to do this. In particular maliciously created objects may have contact details in them for the wrong people if only the RIPE (non-authoritative) object is looked at, and these contacts may have a vested interest in keeping their object. I understand that this could complicate processing of potential concerns in cases where disagreements may come up, but to me it seems more important that the real current holders of the resources should have the bigger say in this. Tim
On 4 Jun 2019, at 15:21, Alexander Azimov <a.e.azimov@gmail.com <mailto:a.e.azimov@gmail.com>> wrote:
I was opposing the first version of this proposal, where conflicting objects were silently and instantly removed. The new version seems to resolve these concerns - and 7-day notification should be fine.
But I'm not sure if all objects have optional 'notify' field (and a brief check showed that there are some without this field, I don't have exact numbers at the moment). If there is the technical opportunity I would suggest to also use notify field (and may be other contacts) from the related maintainer object.
пт, 31 мая 2019 г. в 14:11, Tore Anderson <tore@fud.no <mailto:tore@fud.no>>: * Marco Schmidt
A new version of RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", is now available for discussion.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
Eminently sensible. Supported.
Tore
-- Best regards, Alexander Azimov
participants (11)
-
Alexander Azimov -
Andreas Larsen -
Ben Maddison -
Cosmin Lupu -
Hansen, Christoffer -
Jared Mauch -
Job Snijders -
Marco Schmidt -
Sebastian Wiesinger -
Tim Bruijnzeels -
Tore Anderson