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
>>