Hi Joao, Many thanks for your posting. We have had some discussions at the Secretariat about the proposed values and have the following comments (see below): On Fri, 31 May 2002, Joao Luis Silva Damas wrote:
[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **]
Dear all,
the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user.
Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are:
o TLA o SubTLA o NLA o SLA
This notation has been deprecated and it is time to adapt the database.
Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users.
As such, we propose to modify the "status" attribute of the inet6num object to be:
a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object
b) have the following possible values: RIR-allocated LIR-allocated Assigned
It would seem desirable to us to go for consistency with the values used in IPv4 in the status field, since intrinsically they are the same arent they? (or are we missing something?) This would also seem to make strong sense from a user perspective in terms of ease of use. In addition, I seem to remember (as in ripe-127?) the main reason for introducing the "status" field, was to assist in the identification of address space as PA or PI. With the values suggested: RIR-allocated LIR-allocated Assigned this does not seem possible anymore. The only complication as far as I can see is that the APNIC and RIPE db's differ slightly on terminology used, but since this can be accommodated in IPv4, then it shouldnt be a problem in IPv6 right? To clarify, the values that APNIC would prefer to use are: ALLOCATED PORTABLE ALLOCATED NON-PORTABLE ASSIGNED PORTABLE ASSIGNED NON-PORTABLE As I mentioned before, these values would be consistent with those in IPv4 (which take effect in August when the migration to version 3 of the RIPE database is complete). Comments? cheers, Anne --
to be used according to the following set of rules:
The RIR-allocated status can only be used in objects representing allocations created directly by the RIR.
The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status.
The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc)
We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space.
A possible transition to the new values could be:
1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated.
Best regards, Joao Damas RIPE NCC * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net *