Dear colleagues, We have been working on the implementation of 2013-04, "Resource Certification for non-RIPE NCC Members", and would like to give you an overview of our proposed plan for certifying address space held by Provider Independent (PI) End Users. You can find the full details below. In summary: 1. We propose to only issue certificates for PI End User resources if an End User Assignment Agreement has been submitted and verified by the RIPE NCC and all internal RIPE Registry records match with the associated information in the RIPE Database 2. Users will no longer be able to update the "org-name:” attribute in the organisation object without RIPE NCC involvement. This attribute will only be locked if the organisation object is referenced from a resource object. With this step we are enforcing an existing business rule. 3. RIPE NCC Access authorisation will be added to the RIPE Database. This will simply be an additional value for the "auth:" attribute, referencing your RIPE NCC Access account. Detailed explanation: Currently, when a PI resource is assigned to an End User, we make a record of the organisation name and the organisation-id in our registry. This information is reflected in the related inetnum object for the resource (the org-id attribute), as well as the organisation object (the org-name attribute). However, it is possible that these informational elements can fall out of sync, as the End User is free to update these objects without involving the RIPE NCC. This can negatively impact the accuracy of the registry. One of the primary goals of issuing resource certificates is to make the RIPE Registry as accurate and robust as possible. Therefore, we propose to only issue certificates for PI End User resources: 1. If an End User Assignment Agreement has been submitted and verified by the RIPE NCC 2. If all internal RIPE Registry records match with the associated information in the RIPE Database During the request procedure, we would perform checks to see if the resources are eligible for certification. If all of the records in the RIPE Registry and RIPE Database match, the PI End User or Sponsoring LIR would be able to request a certificate without interaction with the RIPE NCC. However, if registry and database information are out of sync, we would ask you to first resolve this (with our help) to ensure that all records match correctly. In this implementation, you will no longer be able to update the "org-name:” attribute in the organisation object without RIPE NCC involvement. This attribute will only be locked if the organisation object is referenced from a resource object. This would ensure that our registry records remain accurate at all times. Additionally, the RIPE NCC plans to launch a project where we will proactively match the RIPE Registry and RIPE Database records in cooperation with the resource holder. Another aspect we need to implement is the association of a RIPE NCC Access account with the person who has authoritative control over the resources. In order to achieve this, we will introduce the ability to add a RIPE NCC Access account to a MNTNER object in the RIPE Database. Practically, this will simply be an additional value for the "auth:" attribute, referencing your RIPE NCC Access account. This will immediately fulfil a long-standing user request to be able to update RIPE Database objects with your RIPE NCC Access account, making authentication between different RIPE NCC services more seamless. Please do not hesitate to contact us if you have any questions. Kind regards Alex Band Product Manager RIPE NCC