'route:' object authorisation
Hi all, Over on the DB-WG list at the moment there's a discussion that participants of this WG may be interested in. George Michaelson of APNIC has said that APNIC's approval process for route objects currently goes like this:
For your information, APNIC Hostmasters have moved to a mode of operation where for inetnum owners where the AS holder is not the same person, and a request is lodged with helpdesk for assistance, the hostmasters manually override and create the object for the inetnum holder, only removing it if an AS holder objects. The inetnum holder needs to be recognised in our systems.
Its a hand-mediated inetnum-only route object. Previous practice was to wait for explicit approval from the AS holder. Now, its created first, and withdrawn if there is an objection.
There have been no complaints. APNIC HM are considering portal changes and other process work to automate this.
The holder of the aut-num is sent an email asking them to contact APNIC if they would like the route object to be removed. Alex Band has asked for the RIPE community's opinions on whether this would be a good thing for RIPE to implement. If you have an opinion about it, please speak up! Cheers, Rob
On Thu, Jul 02, 2015 at 03:25:22PM +0100, Rob Evans wrote:
Its a hand-mediated inetnum-only route object. Previous practice was to wait for explicit approval from the AS holder. Now, its created first, and withdrawn if there is an objection.
There have been no complaints. APNIC HM are considering portal changes and other process work to automate this.
The holder of the aut-num is sent an email asking them to contact APNIC if they would like the route object to be removed.
Alex Band has asked for the RIPE community's opinions on whether this would be a good thing for RIPE to implement. If you have an opinion about it, please speak up!
There are a number of advantages to this approach, for instance it makes it far easier to authorise 'foreign' ASNs to announce a prefix. For instance if a RIPE region based inetnum owner wants NTT / AS2914 (an ASN from outside the RIPE region) to announce the prefix on their behalf, to get a route object created in the RIPE IRR, I would have to create a faux copy of autnum AS2914 in the RIPE IRR to jump through the double authorisation hoop. Such faux copies pollute the global IRR system. Aside from APNIC, JPNIC/JPIRR also has positive experiences with the mechanism where the autnum owner is not required to authorise route-object creation, only the inetnum owner. If the community shows sufficient support for this direction, we'll draw up an implementation plan and formulate the fine print and all details. Kind regards, Job
Yes, that would make life a lot easier. As I've discovered very recently. Best regards, Paul Hoogsteder Meanie AS31019 Breedband Delft AS34108
Hi all,
Over on the DB-WG list at the moment there's a discussion that participants of this WG may be interested in.
George Michaelson of APNIC has said that APNIC's approval process for route objects currently goes like this:
For your information, APNIC Hostmasters have moved to a mode of operation where for inetnum owners where the AS holder is not the same person, and a request is lodged with helpdesk for assistance, the hostmasters manually override and create the object for the inetnum holder, only removing it if an AS holder objects. The inetnum holder needs to be recognised in our systems.
Its a hand-mediated inetnum-only route object. Previous practice was to wait for explicit approval from the AS holder. Now, its created first, and withdrawn if there is an objection.
There have been no complaints. APNIC HM are considering portal changes and other process work to automate this.
The holder of the aut-num is sent an email asking them to contact APNIC if they would like the route object to be removed.
Alex Band has asked for the RIPE community's opinions on whether this would be a good thing for RIPE to implement. If you have an opinion about it, please speak up!
Cheers, Rob
participants (3)
-
Job Snijders -
Paul Hoogsteder -
Rob Evans