Dear colleagues, Following is the impact analysis for NWI-4 "Role of status: field in multivalued status context", based on the addition of a new status value "ALLOCATED-ASSIGNED PA".
The main drawback identified in this proposal is that an inetnum with status "ALLOCATED-ASSIGNED PA" must remain co-maintained between the RIPE NCC and the LIR, and not by the end user. If an end user is required then the earlier alternative proposal to use a tuple (using both prefix and status) is preferable (although technically more complex). Whois Application * Add a new inetnum status "ALLOCATED-ASSIGNED PA". Treat this status as both ALLOCATED PA and ASSIGNED PA. * New allocations will continue to be created with the "ALLOCATED PA" status. * Allow a user to switch the status to and from (only) "ALLOCATED PA" to "ALLOCATED-ASSIGNED PA" themselves. This allows the user to document a single assignment under the allocation. * Follow the same validation rules for both ALLOCATED PA and ASSIGNED PA. This new status has no impact on the validation rules (i.e. no conflict was found between the two status values). * Support the same status hierarchy for ALLOCATED-ASSIGNED PA as for ALLOCATED PA or ASSIGNED PA (e.g. SUB-ALLOCATED PA, LIR-PARTITIONED PA etc.). * An inetnum with status "ALLOCATED-ASSIGNED PA" remains co-maintained by the RIPE NCC. * The inetnum primary key remains the IPv4 address range. Using the same address range with different status values is not allowed. Registry Services * The "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" policy (currently RIPE-733) requires that "All assignments and allocations must be registered in the RIPE Database". This proposal addresses this requirement. * If an LIR wants to create an assignment because they want to document an assignment to an end user, this proposal will not help in this case. The ALLOCATED-ASSIGNED PA inetnum remains co-maintained between the LIR and the RIPE NCC, and not by an end user maintainer. Also any contacts (admin-c, tech-c, abuse-c etc.) are for the LIR and not the end user. * What is missing is that an LIR can not specify an end user customer’s mnt-by and, most importantly, cannot specify the customer’s organisation object. Internal Registry * No impact is expected to the internal registry software. No direct parsing of the status attribute for either inetnum objects was found in interactions with Whois (e.g. organisation changes and transfers). Whois Clients * Clients reading the inetnum status: value must be updated to take account of the "ALLOCATED-ASSIGNED PA" status and treat it as equivalent to both an "ALLOCATED PA" and "ASSIGNED PA" status. Regards Ed Shryane RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
