[db-wg] In-band notification mechanism?
Cynthia Revström me at cynthia.re
Sun Mar 24 10:37:18 CET 2019
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 at 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 at ripe.net > <mailto:db-wg at 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 at ams-ix.net <mailto:aris.lambrianidis at 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 at yahoo.co.uk <mailto: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> <mailto: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: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20190324/ee314bf8/attachment.html>
[ db-wg Archives ]