Hi Denis,In NRTM, the client sets up a connection with the server and then with a persistent connection the server sends updates via that connection.Please see the details here https://www.ripe.net/manage-ips-and-asns/db/support/documentation/mirroring- CynthiaExcuse my brevity, this was typed on a phone.On 24 Mar 2019 13:51, ripedenis@yahoo.co.uk wrote:HI guysYou seem to now be suggesting that a form of NRTM for only routing information (IRR data) and open to anyone without a contract would satisfy what you are looking for. I thought NRTM is a pull mechanism not a push? Aris mentioned you need this info to 'create filters'. Not being a routing expert, is this something you do periodically or in real time as routing information changes? If it's periodically then to pull an edited NRTM stream, only containing operational routing data updates, would work. If you want changes to routing data in the RIPE Database to trigger filter creation then you do need a new push mechanism.cheersdenisco-chair DB-WGOn Sunday, 24 March 2019, 11:58:40 CET, Cynthia Revström via db-wg <db-wg@ripe.net> wrote:Hi Job,
I guess you have a point seeing as the non-realtime DB files are public
without any paperwork.
- Cynthia
On 2019-03-24 10:46, Job Snijders wrote:
> In order to provide the most value to RIPE NCC's members, I'd argue
> that we need to remove ALL the paperwork e.g. allow any IP address to
> set up a NRTM stream for the purpose of mirroring IRR objects that
> contain routing information: route/route6/route-set/as-set. NTT is
> mirroring the RIPE database at rr.ntt.net and we filter away anything
> non-routing anyhow.
>
> The current NRTM agreement poses a significant barrier, the barrier
> can be easily be circumvented; so it only causes harm.
>
> Having an agreement in place for IRR data that contains PII,
> Organisation or any non-routing information is fine with me. That data
> has no value in router configuration automation pipelines anyway.
>
> Kind regards,
>
> Job