I am trying to understand how this change could {help,hinder} the APNIC problem of route objects which reference differently maintained AS and Inetnum objects, and the added complication of AS being vested from RIPE and Inetnum from APNIC. I think stripping/changing the notify-on-ref mail might hinder this. It would be materially useful to preserve it, should exported IRR state be used at another site aggregating data, to contact the prime information manager. I suspect RPSS/RPSAUTH issues are out of scope. Within one IRR/RPSL data set, I think the notify-on-ref thing would help the APNIC problem: it would make it easier for non-related maintainer to understand changes were being made in routing by address holders who want their AS to be in a route object, and participate. -George On Wed, Jun 11, 2014 at 5:13 AM, Sander Steffann <sander@steffann.nl> wrote:
Hi Job,
I think some notification feature would be nice to have, but we need to figure out what and when we expect notifications.
I propose we dub the attribute for nice alignment with existing attributes:
notify-on-ref: <email-address> optional, multi-valued
Questions:
- do you want a notification each time an object is updated and has a reference to your object?
Strong no
- or do you only want notifications when a reference inititally is added to an object? (spares you a daily mailbomb for daily updated objects)
Yes
- do you want a notification when the reference is removed from an object?
Yes
- In what classes do you want to set a notify-on-ref attribute? (I think initially aut-num, as-set, rd-set)
Ack
- do we want the notify-on-ref email addresses to be set to unread@ripe.net upon NRTM/ftp export?
No strong opinion on this one. I would say yes, unless someone comes up with a reason not to.
Regarding authorisation, for me requiring authorisation to reference a given object is a bridge too far at this point in time. Quite some operators automatically generate an autnum, route-sets & as-sets on a daily basis to reject their policy, and I don't see an easy way to make this a painless adventure. Let's first do notifications and based on those experiences look further. ok?
Yes, that sounds reasonable. Needing authorisation to be allowed to put information in the policy sounds like a good way to discourage people from updating/using them altogether. Let's not make things more difficult unless we really need to.
Cheers! Sander