[db-wg] In-band notification mechanism?

Dear Aris,

Did you consider consuming a NRTM feed? That’s an approach that already
exists.

Kind regards,

Job

On Sat, Mar 23, 2019 at 19:22 Aris Lambrianidis via db-wg <db-wg at ripe.net>
wrote:

> Hi Denis,
>
> We, and other IXPs, create filters (prefix-lists) for services such as
> route servers, by parsing aut-num and as-set objects from IRR databases,
> such as the RIPE database, using tools such as bgpq3.
>
> Right now, to the best of my knowledge, the only way to maintain those
> filters up to date for all of our route server peers, is to periodically
> poll IRR databases for changes.
> IMO it would seem more efficient if the database itself notified us of any
> changes, rather than us constantly asking the same question(s).
>
> Does this make sense?
>
> That said, I can also think of other use cases in which interested parties
> having no direct relationship to certain objects and their maintainers are
> interested in finding out of any changes,
> especially in the field of research, but let me not delve into this and
> keep things simple for the time being.
>
> Kind regards,
> Aris
>
>
> ripedenis at yahoo.co.uk wrote on 23/03/2019 02:26:
>
> Hi Aris
>
> Can you clarify one point about this. Are you saying you want to be
> notified if someone changes their data that you have no direct relationship
> with? So if I maintain a set object and you are not part of my company and
> have no direct business relationship with me and I have no idea who you
> are, but if I modify this object you want to be notified?
>
> cheers
> denis
> co-chair DB-WG
>
> On Saturday, 23 March 2019, 01:02:48 CET, Aris Lambrianidis via db-wg
> <db-wg at ripe.net> <db-wg at ripe.net> wrote:
>
>
> Hi Wilfried,
>
> Thank you for the effort in helping out!
>
> Unfortunately this will not do as:
>
> 1. It notifies via an "out-of-band" method (i.e. email). This makes
> it difficult (but not impossible) to handle with automation.
> Nonetheless, the
> more elegant way would be through an API leveraging a push mechanism.
>
> but more importantly:
>
> 2. the "notify:" attribute has to actually be configured with an address
> of the
> interested party for it to work.
>
> However I'm looking for mechanism for interested parties to be notified of
> any changes in objects independently to what the maintainer has configured
> as a notify address.
>
> Kind regards,
> Aris
>
>
> Wilfried Wöber wrote on 22/03/2019 21:50:
> > Hi Aris!
> >
> > Is this what you are looking for?
> >
> >
> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/notifications/9-2-notification-messages/9-2-1-notification-attributes
> >
> > I may be off-track, of course :-)
> > Wilfried
> >
> > On 22/03/2019 20:29, Aris Lambrianidis via db-wg wrote:
> >> Dear all,
> >>
> >> Back in the day, RFC1996 introduced the NOTIFY mechanism in DNS, which
> significantly helped with information propagation delay,
> >> as it facilitated the transition from a pull (poll) to a push
> (interrupt) model.
> >>
> >> The problem we, as AMS-IX, are facing is quite similar when it comes to
> polling the RIPE database for changes. This seems
> >> inefficient.
> >>
> >> Although the analogy breaks down quickly, as there are no RIPE database
> "clients" similar to DNS slave servers
> >> parsing NOTIFY messages, we would love to see any RIPE API created or
> extended, or any other mechanism implemented by which
> >> a client "registers interest" for any objects it wants to be notified
> of changes.
> >>
> >> As a simple example, if we were to "register interest" (e.g. via a REST
> POST or PUT method) for the AS-AMS-IX-SET as-set object, we would be
> >> programmatically notified whenever the "last-modified" field of the
> as-set was changed.
> >>
> >> Based on the above, I have 3 questions:
> >> 1. Does something like what is described above already exist?
> >> 2. If it doesn't exist, would others be interested on such
> functionality?
> >> 3. If it doesn't exist, while knowing that this is only a high level
> overview of the concept and many details are missing, is this generally
> feasible?
> >>
> >> Kind regards,
> >> Aris Lambrianidis
> >> AMS-IX
> >>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20190323/e002ed2d/attachment.html>