Colleagues
I am working with the RIPE NCC to document the current rules for the
"status:": attribute values. This is not an attempt to simplify or
substantially change the values, although some aspects do need
clarifying. There is no documentation anywhere on what the current
rules are. This information only exists completely in the RIPE
Database software and in the test suite for the database software. The
goal is to describe all the current status rules and relationships in
the RIPE Database documentation.
Some of these rules have never been discussed by the community to the
point of a consensus. Some are interpretations made by the database
developers over the years (myself included) based on comments in
various other discussions. I have some questions that need
clarification from the community. I have listed them below. Some might
seem obvious, but within the software some things are allowed and some
things are not disallowed just because no one has ever specified what
it should (not) be. If you have a strong opinion on any of these
questions, please share it. Any questions that no one comments on,
then as we have done in the past we will document 'an interpretation'.
If the community accepts the resulting documentation, the software
will be adjusted accordingly.
cheers
denis
1/ Is there a use case for AGGREGATED-BY-LIR more specific to
AGGREGATED-BY-LIR? If so, to how many levels?
2/ Is there a use case for LIR-PARTITIONED PA more specific to
ALLOCATED UNSPECIFIED?
3/ Is there a use case for LIR-PARTITIONED PA more specific to SUB-ALLOCATED PA?
As the name suggests, it was introduced to partition an allocation.
There are currently about 438 hierarchies with LIR-PARTITIONED PA more
specific to SUB-ALLOCATED PA in the database.
4/ Is there a use case for LIR-PARTITIONED PA more specific to
LIR-PARTITIONED PA? If so, to how many levels?
There are currently about 83 hierarchies with LIR-PARTITIONED PA more
specific to LIR-PARTITIONED PA in the database. They only exist to two
levels.
5/ Should we say that SUB-ALLOCATED PA 'must' be defined in the RIPE
Database? This is not clear in the address policy. As we move to a
world where not everything must be defined in the database, we
probably should be clear about what must be defined there. (Which may
require an update to the address policy.)
6/ There are currently multiple levels of SUB-ALLOCATED PA in the
database. The max that exists at the moment is 4 levels of
SUB-ALLOCATED PA. Is that a reasonable level to set as a limit? Or
should we not allow it at all?
7/ Should there be a limit on the number of levels in a LEGACY hierarchy?
