Hi, Following up on the AP policy WG discussion: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-October/01194... If/when implemented it would eventually break up large contiguous inetnums with status ALLOCATED PI/UNSPECIFIED into smaller prefixes. As a consequence, route aggregation will be lost since when the parent inetnum is removed from the RIPE DB, the equivalent route will be removed as well. The current RIPE DB process and rules are not allowing for a /23 route to be created out of two /24s bit boundary contiguous prefixes registered as separate /24s without a common parent range. This is something that could be remedied by allowing a parent route to be created, the system could be rather easily implemented using the current DB rules layout. Existing inetnum objects in DB: inetnum: x.x.x.0/24 mnt-routes: ASXXXX-mnt mnt-by: prefix-holderA-mnt inetnum: x.x.y.0/24 mnt-routes: ASXXXX-mnt mnt-by: prefix-holderB-mnt Submission to the DB update: route: x.x.x.0/23 origin: AS-mnt mnt-by: ASXXXX-mnt authentication credentials for ASXXXX-mnt The DB would currently only look for an exact match and if none found, it will look for a less specific inetnum to authenticate the route creation. So today such an update would get rejected as you would not be able to authenticate whatever is above the /23. If it is changed to look for an exact match, then for more specifics with a matching summary to the route object prefix and then for a less specific, the creation of parent route would be allowed as part of the second step in the checks in the creation logic mechanism. It would not change the current authentication system logic, all will continue to work as it is today. Things to consider: A) Recall mechanism. To allow a prefix holders to recall a route object from a less specific route objects just like they today can with exact match and more specifics. Notifications could then be sent to the involved parties about the route recall having taken place. B) RIPE-NCC-RPSL-MNT! If the above mechanism was to be introduced, that maintainer could then create less specific route for any range, restrictions would need to be implemented in order to prevent mistakes or abuse of RIPE-NCC-RPSL-MNT. C) Adding this to the IRR wizard Alex Band described at the DB WG session. Simple interface and overview of what could be aggregated. D) Could any of this have any negative effect in the RIPE Database? E) Should this also be passed through the routing WG? Cheers, David Hilario