In-band notification mechanism?
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
Hi Aris! Is this what you are looking for? https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... 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
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-datab...
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
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? cheersdenisco-chair DB-WG On Saturday, 23 March 2019, 01:02:48 CET, Aris Lambrianidis via db-wg <db-wg@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-datab...
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
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@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@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-datab...
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
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@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@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@ripe.net> <db-wg@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-datab...
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
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
significantly helped with information propagation delay, 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
Hi Job, AFAIK (and perhaps I'm missing something) an NRTM feed has a few drawbacks: 1. It still is a pull rather than a push mechanism 2. It doesn't allow any granularity to receiving only specific objects: We would need to receive all of the database as-set and aut-num objects and parse them for the ones we're interested in 3. It needs some red tape before being able to consume it Kind regards, Aris Job Snijders wrote on 23/03/2019 20:05:
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@ripe.net <mailto:db-wg@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@yahoo.co.uk <mailto:ripedenis@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@ripe.net> <mailto:db-wg@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-datab... > > 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 >>
Hi Aris, see responses in line. On 2019-03-23 20:31, Aris Lambrianidis via db-wg wrote:
1. It still is a pull rather than a push mechanism
You set up a connection to the RIPE NRTM service, then it pushes.
2. It doesn't allow any granularity to receiving only specific objects: We would need to receive all of the database as-set and aut-num objects and parse them for the ones we're interested in You can filter out the ones you don't want in your software, I like using IRRd4 and mirror the databases I want and then just connect to the Postgres DB. 3. It needs some red tape before being able to consume it
Not much to say here, it is true - Cynthia
Hi Aris This is what I was thinking you were looking for. I just wanted to be clear. Knowing how the database is structured I can think of ways of doing this, but it would be for the RIPE NCC to assess feasibility. I think it may be easier to do it as a service to members than making it a more general feature for anyone. Does anyone else agree on the need for such a feature? If so perhaps we can create a new Numbered Work Item. cheersdenisco-chair DB-WG On Saturday, 23 March 2019, 19:21:01 CET, Aris Lambrianidis <aris.lambrianidis@ams-ix.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@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? cheersdenisco-chair DB-WG On Saturday, 23 March 2019, 01:02:48 CET, Aris Lambrianidis via db-wg <db-wg@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-datab...
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
Hi Dennis, If this were made possible, I’m curious as to why it would be easier to do as a member only feature? I can see a benefit of this to those who work to protect users of the internet (and those that might not use it but could still be impacted) such as law enforcement and security researchers. For example, it may be the case that an investigation/research identifies abuse in relation to registered objects which could be reported as being identified to be the result of policy violations. An investigation would then be impacted by consequent changes as a result of the policy violations being recognised and immediate knowledge of the changes would serve to best direct the course of an investigation. Thanks, Liam
On 23 Mar 2019, at 21:34, ripedenis--- via db-wg <db-wg@ripe.net> wrote:
Hi Aris
This is what I was thinking you were looking for. I just wanted to be clear. Knowing how the database is structured I can think of ways of doing this, but it would be for the RIPE NCC to assess feasibility. I think it may be easier to do it as a service to members than making it a more general feature for anyone.
Does anyone else agree on the need for such a feature? If so perhaps we can create a new Numbered Work Item.
cheers denis co-chair DB-WG
On Saturday, 23 March 2019, 19:21:01 CET, Aris Lambrianidis <aris.lambrianidis@ams-ix.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@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@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-datab...
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
Hi All I haven't given this any in depth thought yet so it was only my initial reaction. The way I was thinking is that we already have a request for creating groups of SSO credentials for maintaining objects that could be managed using the portal UI. Perhaps registering an interest in being notified of changes to an operational/resource object could also be done using the portal UI. If a more general service is wanted there may be other issues to consider, for example:-who should be allowed to monitor changes to data in this way?-is there a need to know what objects are being monitored and by who?-if so only by the object maintainer or public disclosure?-does anyone need to know anything about those who are monitoring objects?-what interface could be used for 'anyone' to register an interest in monitoring an object?-how are they going to be notified of changes?-the original request could be considered as an operational issue relevant to the purpose of the database as defined by the Terms and Conditions, if we allow monitoring of any (operational/resource) object for any reason by anyone are there any legal implications?-should there be limits on how many objects anyone can monitor?-if so how could that be enforced?-the NRTM service is only available to members subject to signing a contract for it's use and accepting it's Terms and Conditions. By registering an interest in monitoring changes to a 'substantial' number of objects, it is in effect (a limited version of) NRTM without a contract-should there be a contract for anyone wanting to monitor changes with Terms and Conditions attached?-... If the community wants such a general service then all such issues can be looked at, but it is widening the scope. cheersdenisco-chair DB-WG On Saturday, 23 March 2019, 23:02:58 CET, Liam Glover <ldglover20@aol.com> wrote: Hi Dennis, If this were made possible, I’m curious as to why it would be easier to do as a member only feature? I can see a benefit of this to those who work to protect users of the internet (and those that might not use it but could still be impacted) such as law enforcement and security researchers. For example, it may be the case that an investigation/research identifies abuse in relation to registered objects which could be reported as being identified to be the result of policy violations. An investigation would then be impacted by consequent changes as a result of the policy violations being recognised and immediate knowledge of the changes would serve to best direct the course of an investigation. Thanks,Liam On 23 Mar 2019, at 21:34, ripedenis--- via db-wg <db-wg@ripe.net> wrote: Hi Aris This is what I was thinking you were looking for. I just wanted to be clear. Knowing how the database is structured I can think of ways of doing this, but it would be for the RIPE NCC to assess feasibility. I think it may be easier to do it as a service to members than making it a more general feature for anyone. Does anyone else agree on the need for such a feature? If so perhaps we can create a new Numbered Work Item. cheersdenisco-chair DB-WG On Saturday, 23 March 2019, 19:21:01 CET, Aris Lambrianidis <aris.lambrianidis@ams-ix.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@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? cheersdenisco-chair DB-WG On Saturday, 23 March 2019, 01:02:48 CET, Aris Lambrianidis via db-wg <db-wg@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-datab...
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
Hi, I mean one thing that has to be considered is that what I think of as the portal UI is only available to LIRs, so on a quick consideration, to me it doesn't really seem to help all that much to add NRTM to it. A limit on how many objects could be monitored wouldn't really make sense imo. I don't think we want to make it complicated and require a new protocol as NRTM is a sort of a standard and not just RIPE makes it available but other IRRs too. I have not thought this through that much but I think the following might be good: - Have a contract with a ToC attached to anyone wanting to use NRTM. - Remove the requirement to be a member of the NCC. So pretty much just a be a member or sign this agreement but with no further changes, that is my idea. I am definitely open to arguments, but this was just what seemed logical to me on a quick thought. - Cynthia On 2019-03-24 01:30, ripedenis--- via db-wg wrote:
Hi All
I haven't given this any in depth thought yet so it was only my initial reaction. The way I was thinking is that we already have a request for creating groups of SSO credentials for maintaining objects that could be managed using the portal UI. Perhaps registering an interest in being notified of changes to an operational/resource object could also be done using the portal UI.
If a more general service is wanted there may be other issues to consider, for example: -who should be allowed to monitor changes to data in this way? -is there a need to know what objects are being monitored and by who? -if so only by the object maintainer or public disclosure? -does anyone need to know anything about those who are monitoring objects? -what interface could be used for 'anyone' to register an interest in monitoring an object? -how are they going to be notified of changes? -the original request could be considered as an operational issue relevant to the purpose of the database as defined by the Terms and Conditions, if we allow monitoring of any (operational/resource) object for any reason by anyone are there any legal implications? -should there be limits on how many objects anyone can monitor? -if so how could that be enforced? -the NRTM service is only available to members subject to signing a contract for it's use and accepting it's Terms and Conditions. By registering an interest in monitoring changes to a 'substantial' number of objects, it is in effect (a limited version of) NRTM without a contract -should there be a contract for anyone wanting to monitor changes with Terms and Conditions attached? -...
If the community wants such a general service then all such issues can be looked at, but it is widening the scope.
cheers denis co-chair DB-WG
On Saturday, 23 March 2019, 23:02:58 CET, Liam Glover <ldglover20@aol.com> wrote:
Hi Dennis,
If this were made possible, I’m curious as to why it would be easier to do as a member only feature?
I can see a benefit of this to those who work to protect users of the internet (and those that might not use it but could still be impacted) such as law enforcement and security researchers. For example, it may be the case that an investigation/research identifies abuse in relation to registered objects which could be reported as being identified to be the result of policy violations. An investigation would then be impacted by consequent changes as a result of the policy violations being recognised and immediate knowledge of the changes would serve to best direct the course of an investigation.
Thanks, Liam
On 23 Mar 2019, at 21:34, ripedenis--- via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote:
Hi Aris
This is what I was thinking you were looking for. I just wanted to be clear. Knowing how the database is structured I can think of ways of doing this, but it would be for the RIPE NCC to assess feasibility. I think it may be easier to do it as a service to members than making it a more general feature for anyone.
Does anyone else agree on the need for such a feature? If so perhaps we can create a new Numbered Work Item.
cheers denis co-chair DB-WG
On Saturday, 23 March 2019, 19:21:01 CET, Aris Lambrianidis <aris.lambrianidis@ams-ix.net <mailto:aris.lambrianidis@ams-ix.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@yahoo.co.uk <mailto:ripedenis@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@ripe.net> <mailto:db-wg@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-datab...
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,
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
which significantly helped with information propagation delay, 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
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
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
HI guys You 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-WG On 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
On Sun, Mar 24, 2019 at 12:51:52PM +0000, ripedenis@yahoo.co.uk wrote:
You 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.
Yes.
I thought NRTM is a pull mechanism not a push?
A client connects to the NRTM server, and asks "did anything change since serial X?" where serial X is the last serial the client saw.
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?
Filters are generated 'periodically', perhaps once a minute! But not 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.
indeed. Kind regards, Job
Hi Denis, To attack this from a different angle and help illustrate my point, an analogy to Twitter comes to mind: Users can follow other users and automatically get notifications of any updates. Having similar functionality for publicly available information such as aut-num and as-set objects would be wonderful. As others pointed out already, I really don't see any privacy or confidentiality issues around this, the data is already publicly available, and in fact in our case we already monitor such objects, just in a less efficient manner. What's more, if we don't monitor them frequently enough, our customers (who maintain the objects we monitor) are the ones being affected by a potentially out of date filter. As for the technical side of things, I'm pretty sure we can agree on a best way forward. Kind regards, Aris ripedenis@yahoo.co.uk wrote on 24/03/2019 01:30:
Hi All
I haven't given this any in depth thought yet so it was only my initial reaction. The way I was thinking is that we already have a request for creating groups of SSO credentials for maintaining objects that could be managed using the portal UI. Perhaps registering an interest in being notified of changes to an operational/resource object could also be done using the portal UI.
If a more general service is wanted there may be other issues to consider, for example: -who should be allowed to monitor changes to data in this way? -is there a need to know what objects are being monitored and by who? -if so only by the object maintainer or public disclosure? -does anyone need to know anything about those who are monitoring objects? -what interface could be used for 'anyone' to register an interest in monitoring an object? -how are they going to be notified of changes? -the original request could be considered as an operational issue relevant to the purpose of the database as defined by the Terms and Conditions, if we allow monitoring of any (operational/resource) object for any reason by anyone are there any legal implications? -should there be limits on how many objects anyone can monitor? -if so how could that be enforced? -the NRTM service is only available to members subject to signing a contract for it's use and accepting it's Terms and Conditions. By registering an interest in monitoring changes to a 'substantial' number of objects, it is in effect (a limited version of) NRTM without a contract -should there be a contract for anyone wanting to monitor changes with Terms and Conditions attached? -...
If the community wants such a general service then all such issues can be looked at, but it is widening the scope.
cheers denis co-chair DB-WG
On Saturday, 23 March 2019, 23:02:58 CET, Liam Glover <ldglover20@aol.com> wrote:
Hi Dennis,
If this were made possible, I’m curious as to why it would be easier to do as a member only feature?
I can see a benefit of this to those who work to protect users of the internet (and those that might not use it but could still be impacted) such as law enforcement and security researchers. For example, it may be the case that an investigation/research identifies abuse in relation to registered objects which could be reported as being identified to be the result of policy violations. An investigation would then be impacted by consequent changes as a result of the policy violations being recognised and immediate knowledge of the changes would serve to best direct the course of an investigation.
Thanks, Liam
On 23 Mar 2019, at 21:34, ripedenis--- via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote:
Hi Aris
This is what I was thinking you were looking for. I just wanted to be clear. Knowing how the database is structured I can think of ways of doing this, but it would be for the RIPE NCC to assess feasibility. I think it may be easier to do it as a service to members than making it a more general feature for anyone.
Does anyone else agree on the need for such a feature? If so perhaps we can create a new Numbered Work Item.
cheers denis co-chair DB-WG
On Saturday, 23 March 2019, 19:21:01 CET, Aris Lambrianidis <aris.lambrianidis@ams-ix.net <mailto:aris.lambrianidis@ams-ix.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@yahoo.co.uk <mailto:ripedenis@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@ripe.net> <mailto:db-wg@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-datab...
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,
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
which significantly helped with information propagation delay, 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
I am in favor of making this a feature available to non-members aswell, but due to how it is structured you might still want a whitelist, but remove the requirement for membership. - Cynthia On 2019-03-23 22:34, ripedenis--- via db-wg wrote:
Hi Aris
This is what I was thinking you were looking for. I just wanted to be clear. Knowing how the database is structured I can think of ways of doing this, but it would be for the RIPE NCC to assess feasibility. I think it may be easier to do it as a service to members than making it a more general feature for anyone.
Does anyone else agree on the need for such a feature? If so perhaps we can create a new Numbered Work Item.
cheers denis co-chair DB-WG
On Saturday, 23 March 2019, 19:21:01 CET, Aris Lambrianidis <aris.lambrianidis@ams-ix.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@yahoo.co.uk <mailto:ripedenis@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@ripe.net> <mailto:db-wg@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-datab...
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,
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
which significantly helped with information propagation delay, 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
I am also in favor of making this available to non-members. I am not against requiring some form of red tape like the current NRTM solution. The reason that it would be valuable outside of members would be for IXPs outside of the RIPE zone that have members who are within the RIPE zone. Thanks ~ Bryce Wilson, AS202313, EVIX, AS137933/AS209762
On Mar 23, 2019, at 2:34 PM, ripedenis--- via db-wg <db-wg@ripe.net> wrote:
Hi Aris
This is what I was thinking you were looking for. I just wanted to be clear. Knowing how the database is structured I can think of ways of doing this, but it would be for the RIPE NCC to assess feasibility. I think it may be easier to do it as a service to members than making it a more general feature for anyone.
Does anyone else agree on the need for such a feature? If so perhaps we can create a new Numbered Work Item.
cheers denis co-chair DB-WG
On Saturday, 23 March 2019, 19:21:01 CET, Aris Lambrianidis <aris.lambrianidis@ams-ix.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@yahoo.co.uk <mailto:ripedenis@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@ripe.net> <mailto:db-wg@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-datab... <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
participants (7)
-
Aris Lambrianidis -
Bryce Wilson -
Cynthia Revström -
Job Snijders -
Liam Glover -
ripedenis＠yahoo.co.uk -
Wilfried Wöber