Re: [routing-wg] Notification/authorisation of references to aut-num from other RPSL objects
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
On Wed, Jun 11, 2014 at 12:55:05PM +1000, 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.
Can you elaborate on what the problem precisely is?
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.
To contact the owner of a resource there are other mechanisms (abuse-c, admin-c, contact-c, etc). I would deem the notify-on-ref email address only relevant for communication between the registry and the email address being notified. It should not concern others who is notified when a resource is referenced.
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.
I am not sure I follow which problem or concern you are addresssing. Can you maybe use an example? Kind regards, Job
Hi,
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.
To contact the owner of a resource there are other mechanisms (abuse-c, admin-c, contact-c, etc). I would deem the notify-on-ref email address only relevant for communication between the registry and the email address being notified. It should not concern others who is notified when a resource is referenced.
So how about notifying an ASN holder in the RIPE region about a policy reference bring changed in the APNIC database? Cheers, Sander
On Wed, Jun 11, 2014 at 05:15:54PM +0300, Sander Steffann wrote:
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.
To contact the owner of a resource there are other mechanisms (abuse-c, admin-c, contact-c, etc). I would deem the notify-on-ref email address only relevant for communication between the registry and the email address being notified. It should not concern others who is notified when a resource is referenced.
So how about notifying an ASN holder in the RIPE region about a policy reference bring changed in the APNIC database?
Today that would not be trivial.. It would not be aligned with current behaviour that RIPE mirrors or monitors other registries and their objects. Kind regards, Job
At 14:42 11/06/2014 +0000, Job Snijders wrote:
On Wed, Jun 11, 2014 at 05:15:54PM +0300, Sander Steffann wrote:
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.
To contact the owner of a resource there are other mechanisms (abuse-c, admin-c, contact-c, etc). I would deem the notify-on-ref email address only relevant for communication between the registry and the email address being notified. It should not concern others who is notified when a resource is referenced.
So how about notifying an ASN holder in the RIPE region about a policy reference bring changed in the APNIC database?
Today that would not be trivial.. It would not be aligned with current behaviour that RIPE mirrors or monitors other registries and their objects.
Let's start someplace. Once the other RIRs see how great and wonderful notify-on-ref is inside the RIPE region in 2015, they will implement it as well (2016-2018), and then by 2019, the other RIRs will have to get together and decide how to mirror and monitor the references between each other. Rome wasn't built in a day. -Hank
Kind regards,
Job
On 11 Jun 2014, at 17:20, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
At 14:42 11/06/2014 +0000, Job Snijders wrote:
On Wed, Jun 11, 2014 at 05:15:54PM +0300, Sander Steffann wrote:
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.
To contact the owner of a resource there are other mechanisms (abuse-c, admin-c, contact-c, etc). I would deem the notify-on-ref email address only relevant for communication between the registry and the email address being notified. It should not concern others who is notified when a resource is referenced.
So how about notifying an ASN holder in the RIPE region about a policy reference bring changed in the APNIC database?
Today that would not be trivial.. It would not be aligned with current behaviour that RIPE mirrors or monitors other registries and their objects.
Let's start someplace. Once the other RIRs see how great and wonderful notify-on-ref is inside the RIPE region in 2015, they will implement it as well (2016-2018), and then by 2019, the other RIRs will have to get together and decide how to mirror and monitor the references between each other.
Rome wasn't built in a day.
totally agree Joao
Hi, On Wed, Jun 11, 2014 at 06:20:51PM +0300, Hank Nussbacher wrote:
Let's start someplace. Once the other RIRs see how great and wonderful notify-on-ref is inside the RIPE region in 2015, they will implement it as well (2016-2018), and then by 2019, the other RIRs will have to get together and decide how to mirror and monitor the references between each other.
+1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
APNIC runs a fork of the RIPE WHOIS code. We track substantive changes. So if this behaviour is implemented in the code we see, it will appear in APNIC WHOIS/IRR sooner rather than later. I'd say 2015. AfriNIC also tracks RIPE WHOIS code. I'd expect it to arrive there as well. I don't entirely understand how LacNIC and ARIN implement IRR. I suspect traction there would be lower. BTW, I might have been missing deep irony/sarcasm. If I was, sorry for not getting the joke. If you didn't mean this ironically, ignore this Paragraph! -G
On Thu, Jun 12, 2014 at 08:34:49AM +1000, George Michaelson wrote:
APNIC runs a fork of the RIPE WHOIS code. We track substantive changes. So if this behaviour is implemented in the code we see, it will appear in APNIC WHOIS/IRR sooner rather than later. I'd say 2015.
AfriNIC also tracks RIPE WHOIS code. I'd expect it to arrive there as well.
Yes, i expect features like these flow into other RIRs. I imagine the earliest implementation of notify-on-ref will only be able to notify owners of RIPE objects about references made in RIPE objects (and likewise APNIC:APNIC when APNIC imports these commits). "inter-RIR" or "inter-IRR" reference-tracking is something we need to figure out later.
I don't entirely understand how LacNIC and ARIN implement IRR. I suspect traction there would be lower.
As far as I know ARIN runs a very old version of the RIPE Whois server (version 3.10.1 - released 3.5 years ago). *takes his hat off and contemplates in silence* I don't know what LACNIC runs, does not seem to be RIPE or IRRd. Kind regards, Job
On Wed, Jun 11, 2014 at 06:20:51PM +0300, Hank Nussbacher wrote:
At 14:42 11/06/2014 +0000, Job Snijders wrote:
On Wed, Jun 11, 2014 at 05:15:54PM +0300, Sander Steffann wrote:
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.
To contact the owner of a resource there are other mechanisms (abuse-c, admin-c, contact-c, etc). I would deem the notify-on-ref email address only relevant for communication between the registry and the email address being notified. It should not concern others who is notified when a resource is referenced.
So how about notifying an ASN holder in the RIPE region about a policy reference bring changed in the APNIC database?
Today that would not be trivial.. It would not be aligned with current behaviour that RIPE mirrors or monitors other registries and their objects.
Let's start someplace. Once the other RIRs see how great and wonderful notify-on-ref is inside the RIPE region in 2015, they will implement it as well (2016-2018), and then by 2019, the other RIRs will have to get together and decide how to mirror and monitor the references between each other.
Rome wasn't built in a day.
*Reviving old thread* Is there a volunteer who wants to write up a specification/requirements text for discussion on db-wg@ripe.net, and after consensus we can ask RIPE NCC to implement this feature? Kind regards, Job
On 11 Jun 2014, at 7:06 pm, Job Snijders <job@instituut.net> wrote:
On Wed, Jun 11, 2014 at 12:55:05PM +1000, 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.
Can you elaborate on what the problem precisely is?
I presented on this at RIPE Dublin and/or Lublijana. AP region has a large (and growing) community of inetnum holders who are not the AS holder and the dual-authentication issues around securing a route object which references the upstream AS is proving a logistical issue. If this field has the potential to aide in automating processes so that party A, lodging a route object in reference to AS held by B, can see B told efficiently that A needs their permission to lodge the route object, its helping our problem. If it can't do this, then its not relevant. Thats why I said "I'm trying to understand if this helps or hinders the APNIC problem..." I needed to try and understand if this notify field would get to the right person, at the right time.
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.
To contact the owner of a resource there are other mechanisms (abuse-c, admin-c, contact-c, etc). I would deem the notify-on-ref email address only relevant for communication between the registry and the email address being notified. It should not concern others who is notified when a resource is referenced.
Well, I guess I'd seen another sense of use of the field. Thanks for clarifying.
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.
I am not sure I follow which problem or concern you are addresssing. Can you maybe use an example?
Sure. Inetnum holder in India, has upstream using AS assigned by RIPE, maintained by RIPE in RIPE IRR. Inetnum holder maintains Inetnum in APNIC WHOIS. There is no substantive RPSS/RPSAUTH to permit an external reference. They cannot effectively make a route object. RIPES current solution satisfies only database purists: a 'dummy' record can be made in RIPE WHOIS which contextually, to be blunt, is a "lie" -the object in question (Autnum) has to be fictional, because there is no RIPE AS-SET or block over it, to permit it to exist. In effect, the nonce value us there only to satisfy dual-authentical requirements of the route object. "lie" is uncharitable. Its a mechanism to permit RIPE address holders to make route objects without the consent/involvement of the AS holder which is only permitted because the AS holder is not in the RIPE region. If they are, then this mechanism is deprecated, or else functionally impossible since a real AUTNUM exists. (If I have this wrong, I'd love to be corrected but this is how I understand it works) -G
Kind regards,
Job
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@steffann.nl <mailto: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 <mailto: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
participants (7)
-
Denis Walker -
George Michaelson -
Gert Doering -
Hank Nussbacher -
Job Snijders -
João Damas -
Sander Steffann