This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/routing-wg@ripe.net/
[routing-wg] Notification/authorisation of references to aut-num from other RPSL objects
- Previous message (by thread): [routing-wg] Notification/authorisation of references to aut-num from other RPSL objects
- Next message (by thread): [routing-wg] Notification/authorisation of references to aut-num from other RPSL objects
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Denis Walker
denis at ripe.net
Wed Jun 11 11:12:26 CEST 2014
Hi George On 11/06/2014 04:55, George Michaelson wrote: > 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 think you are mixing up notifications with contacts here. Notifications are usually a list of one or more people who want to be notified when something changes. They may not be the same people as the admin-c, tech-c, abuse-c contacts who you would talk to if you have any issues/questions, who may also be different to the maintainers of the data. > > 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. This sounds like you want this notification to be sent if an ASN is associated with a ROUTE object. I presume you don't mean in the "origin:" as this has already been authorised by the ASN holder, so they already know of the association. Or do you want to cover the option of more than the maintainer of the AUT-NUM object wanting to know of the association? There are other attributes in a ROUTE object that can reference an ASN, "aggr-mtd:" and "aggr-bndry:". So do you want this notification to be triggered by a reference here? Regards Denis Walker Business Analyst RIPE NCC Database Team > > -George > > > > On Wed, Jun 11, 2014 at 5:13 AM, Sander Steffann <sander at steffann.nl > <mailto:sander at 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 at ripe.net <mailto:unread at 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/routing-wg/attachments/20140611/06709e7d/attachment.html>
- Previous message (by thread): [routing-wg] Notification/authorisation of references to aut-num from other RPSL objects
- Next message (by thread): [routing-wg] Notification/authorisation of references to aut-num from other RPSL objects
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]