1. It notifies via an "out-of-band" method (i.e. email). This makes
it difficult (but not impossible) to handle with automation.
more elegant way would be through an API leveraging a push mechanism.
2. the "notify:" attribute has to actually be configured with an address
interested party for it to work.
as a notify address.
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
>>