[db-wg] In-band notification mechanism?

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: </ripe/mail/archives/db-wg/attachments/20190324/ee314bf8/attachment.html>