Dear Denis, colleagues,
On 30 Sep 2025, at 02:31, denis walker <ripedenis@gmail.com> wrote:
Colleagues
Some documentation issues were raised during a discussion of contact methods. They have nothing really to do with the issue of contacts so I have started a new thread on the documentation. It is not the most urgent issue regarding the RIPE Database so you may not care about any of this. But documentation should be correct or it is a waste of time having it. If no one comments, maybe the chairs can pass judgement.
Three issues are raised here: -Attribute properties -Description of AGGREGATED-BY-LIR -Missing attribute
Attribute properties ...
As suggested in this thread, unless there are any objections, the DB team will implement "conditional" for an attribute in the object template, in addition to "mandatory", "optional" and "generated". A "conditional" attribute can be mandatory depending on the business rules, we will add a link to the documentation : https://docs.db.ripe.net/Database-Support/Database-Business-Rules
Description of AGGREGATED-BY-LIR This is described in both the database documentation [2] and in the address policy [3]. Neither is an accurate and clear description and they are both different.
In the address policy it says "The purpose and the contact details must be consistent throughout the whole assignment.". This confuses the terms 'aggregation' and 'assignments'. An aggregation is a collection of 'multiple' assignments. So you must either refer to the aggregation or the collection of assignments.You cannot refer to a single assignment. This is not just splitting hairs. For a non native English speaker new to the database, they are reading this to try to work out what this means. The current wording suggests the aggregation represents a single block of assigned address space, rather than a collection of multiple address blocks, possibly of different sizes.
We will re-write this section of the documentation.
The purpose of an assignment is not publicly defined or documented anywhere. What is the purpose of a block of assigned address space? Can it be 'used by an End User's public network' or 'used by the LIR for their own infrastructure'? But then these are two different purposes. So by definition you should not be able to aggregate a mix of End User's address space with an LIR's own infrastructure. Is that the case? How does anyone outside of the LIR know? Should the purpose be documented in a remarks attribute? Should an aggregation have a "purpose:" attribute? It seems like there was such a rush to make individual assignments optional, the actual details of the aggregation were not very well thought through.
What does "the contact details must be consistent" mean? All the assignments have a tech-c? All the tech-c references are to a ROLE object or a PERSON object? They all include an email address? They all refer to the same ROLE object? All the different ROLE objects reference the same email address? It is not good enough to say "but we all know what it means". A new LIR, new to the policy documents, new to the database may not know what this means. That is why they are reading it.
I appreciate any feedback on these points from the community. We will re-write this section to make it clearer.
There is no explicit mention that the multiple assignments can all be of different sizes. Unless the "assignment-size:" attribute is included.
We will update the documentation to make this clear.
Is it sufficient for all these details to be explained in the RIPE Database documentation, that is only advisory? Possibly leaving the policy statement so vague that it is easy to misunderstand or misinterpret. Either way, all of these points need to be explained, somewhere.
I think the DB documentation needs to clearly explain the intention of the policy, including examples, to help the user to comply with the policy. We can also include links back to the policy text.
I haven't even touched on rules that should have so obviously been documented somewhere. For example, if aggregations are created retrospectively, the boundary between aggregations within a single allocation must match the boundaries of the encompassed assignments. If the assignments are deleted before creating the aggregations then the software cannot enforce this and there is no way for anyone to verify this was done. The whole concept of aggregation was badly specified. But that is another story...
We will improve the documentation where it's deficient. I also encourage the community to contribute improvements via the documentation repository : https://github.com/RIPE-NCC/ripe-database-documentation
Missing attribute There is no mention in the documentation of the INETNUM or INET6NUM attribute 'prefixlen'.
Apologies for the omission, we will add the "prefixlen" attribute to the documentation ( https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/ ). Regards Ed Shryane RIPE NCC