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 *

Dear Colleagues, The RIPE NCC needs to implement a new status attribute for the inet6num object to reflect the new policy agreed by the RIPE, ARIN and APNIC communities. The RIPE NCC suggested the following new status attributes for the inet6num objects: - RIR-ALLOCATED (For allocations made by an RIR to an LIR) - LIR-ALLOCATED (For allocations made by an LIR or an LIR's downstream customer to another downstream organisation) - ASSIGNED (For assignments made to End User sites) There was discussion as to whether the terms ALLOCATED and ASSIGNED should be used or whether DELEGATED was the preferred term. It was pointed out that changing the terminology would require a full rewrite of all documentation, web sites and training material referring to these terms. It would also require the re-education of those who are familiar with these terms from IPv4. This process would be expensive. In addition to this, these terms are already defined in Section II of the IPv6 Address Allocation and Assignment Policy document. Changing these terms in the Database would require a significant rewrite to the policy itself. There was also a discussion as to whether the status attribute should reflect the portability of IPv6 address space. In the RIPE NCC Service Region there is a policy allowing /32 blocks to be issued to the networks hosting Root Nameservers. There is also a policy allowing IXP networks to receive a /64 or /48 for neutral peering meshes. However, there is not (yet) a policy allowing End User networks to receive a block of Provider Independent address space. Until there is a policy allowing End Users to carry address space with them when they change providers it is probably not appropriate to give assignments a status indicating that they are *not* portable. For these reasons the RIPE NCC would like to implement the new status attribute, as described on 31 May 2002 and above, as soon as possible. The software implementation will allow configuration of different labeling for the status attribute quite easily. Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager