Denis, all, {ncc services stripped as requested, but dns and db wg kept for now}
What follows is a short proposal to change the process of creating and
it appears that these are actually three proposals that are linked together but might deserve discussion of their own merits.
Feature to be deprecated ------------------------ Currently, we allow a dash in the third octet of an IPv4 reverse delegation. So, for the address range 10.2.1.0 - 10.2.100.255, the syntax allows a reverse delegation DOMAIN object to be submitted as 1-100.2.10.in-addra.arpa. The RIPE Database update software will expand this into 100 separate objects in the database with prefixes from 1.2.10.in-addra.arpa to 100.2.10.in-addra.arpa. Apart from the prefix, all the other data in the submitted object will be duplicated in all 100 objects. To modify or delete this set of objects, the user has to process all 100 objects individually. No bulk operations are possible after the original object has been expanded in the database.
So, there is a macro feature in there that isn't explicit but overlays the object name and key. Also it seems this macro is only useful at object creation time. Can you share any numbers in terms of objects an LIRs that have been using this feature?
This feature is not compatible with using DNSSEC. The value of the "ds-rdata:" attribute is a hash that includes the delegation. By
Well, this is only a consequence of chosing the DS data as the registration object. If that were the only obstacle and provided LIRs are using the same DNSKEY for multiple zones, this could of course be changed to allow for registration of the DNSKEY (identical across whatever macro expansion) to make the data part consistent for all those objects covered.
Feature to be added -------------------
in the RIPE Database, they will not be propagated to the zone files. The RIPE NCC proposes to allow a dash in the fourth octet of an IPv4 reverse delegation. So, for the address range 10.2.1.6 - 10.2.1.25, the syntax would allow a reverse delegation DOMAIN object to be submitted as 6-25.1.2.10.in-addra.arpa. This object would not be expanded by the RIPE Database update software into 20 separate objects, as it is with the feature described above. It would be created in the database as a single object, including the dash in the range.
Sounds reasonable to me for those direct assignments smaller than /24.
New DNS provisioning software would handle the new dash notation and propagate this delegation to the zone file. However, the range 0-255 is a special case and would not be allowed in the fourth octet.
This would suggest the fourth label is evaluated and checked also against the governing inetnum object or authorization? -Peter {no hats}