Hi all, As touched upon during the DB-WG meeting, AMS-IX is in favor of this proposal.
If I understand things correctly, existing functionality is practically maintained, while desired functionality is added which could also be easily extended. Kind regards, Aris Lambrianidis AMS-IX > On 27 May 2019, at 10:58, Edward Shryane via db-wg <[email protected]> wrote: > > Dear Working Group, > > given the Problem Definition for NWI-9: > > "There is a need within the routing community to have changes to > all/nominated routing data objects in the RIPE Database pushed out to them, > regardless of membership status." > > As presented at last week's DB-WG meeting, I'd like to propose a Solution > Definition: > > (1) The current NRTM service is not suitable. > > The current NRTM is a member-only service, with a separate agreement: > https://www.ripe.net/manage-ips-and-asns/db/nrtm-mirroring > > The work needed to change this (including technical changes to open the > service) is greater than providing a re-implementation. > > The existing service will remain available on the same terms. > > (2) Implement a replacement NRTM interface > > The current NRTM is a custom protocol, which is complicated to use, and not > easy to extend without breaking existing clients. > > Instead implement a replacement NRTM interface, based on modern standards. > > - The interface is generally available without needing to be a member, or to > sign an agreement. > - The protocol uses HTTPS and WebSockets, with object data in JSON format. > - A client can request the current available range of updates, and also > request a closed or open range of updates. > - A separator comment is inserted between updates, with an 'end of stream' > comment after each group of updates. > - All object updates are returned, except for person and role objects. > - Personal data is filtered from all object updates, consistent with the > other query interfaces. > - A client can optionally request filtering updates by object type. > - A client can optionally identify themselves by providing credentials. > - The interface can be extended later by adding more request parameters. > > Please let me know what you think. > > Regards > Ed Shryane > RIPE NCC
signature.asc
Description: Message signed with OpenPGP
