Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.0] Default to protected for inetnum, inet6num, and domain objects ----------------------------------------------------------------------- Change: All hierarchical object types will now default to requiring authorisation for more-specific object creation. Motivation: In RPSS, objects use "mnt-lower:" to specify a maintainer which has the ability to authorise the creation more-specific objects. If a "mnt-lower:" attribute is not present, then the "mnt-by:" of the less-specific object is used. For example: route: 192.168.100.0/24 origin: AS1 mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT . . . Authorisation for creation of a more-specific route must be given by ANOTHER-MNT. inetnum: 192.168.200.0/24 origin: AS1 mnt-by: EXAMPLE-MNT . . . Authorisation for creation of a more-specific route must be given by EXAMPLE-MNT (in the absence of an exact match or less specific route object). For object types not defined in RPSS, the current behaviour is as defined in RIPE-181. This includes inetnum, inet6num, and domain objects. In RIPE-181 if no "mnt-lower:" attribute is present, then requests to create more-specific objects require no authorisation from the less-specific inetnum. The proposal is to bring this into line with the new default. For example: inetnum: 192.168.101.0 - 192.168.101.255 mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT . . . Authorisation for creation of a more-specific inetnum must be given by ANOTHER-MNT. inetnum: 192.168.201.0 - 192.168.201.255 mnt-by: EXAMPLE-MNT . . . Authorisation for creation of a more-specific inetnum does NOT currently require authorisation by EXAMPLE-MNT. The proposed change would require authorisation by EXAMPLE-MNT. -- Shane Kerr RIPE NCC