[db-wg] NCC still enforcing descr: content

Dear Jan, Working Group,


> On Jul 27, 2015, at 6:41 PM, Jan Saner <jan at trick77.com> wrote:
> 
> Hello
> 
> Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I’m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is:
> 
> https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html
> 
> Quote:
> -----------------------------------------------------------
> "> When will this change go into effect?
> 
> We were thinking of mid April, for two reasons:
> 
> 1) This gives the working group enough time to comment.
> 
> 2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously."
> -----------------------------------------------------------

Well, in short I misjudged the effort needed for this, and since then I presented an update on this at the RIPE meeting, see slide 4 here:
https://ripe70.ripe.net/wp-content/uploads/presentations/164-ripe70-db-wg-new-functionality.pdf

We are *nearly* done. We have a bit over 100 aut-num objects to work on (as compared to 2000 in May).

When this is fully done, we can present an implementation plan for this soon, within a few weeks. Before we do so, I would like to ask the working group for direction on the following. Because sadly, stopping enforcing this is not as trivial as it might seem.


Option a: Leave existing cases, "descr:" mandatory, update request forms
========================================================================

We would leave existing cases, but note that this can lead to confusion because the names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line.

We would also need to change request forms and processes to make sure that a sensible description is provided (i.e. not the name). This would take some time to implement, but can be done if this is where we need to go.


Option b: Clean up existing cases, "descr:" optional
=====================================================
On the other hand if "descr:" could be optional, we would be able to do a bulk change to remove the existing organisation names from the "descr:" of objects, both for end-user resources as well as for allocations. And then leave it to the holders of these objects to modify as they please. This would be the cleanest in the sense that any remaining "descr:" would be fully maintained by the resource holders, and the one place to look for the organisation name is in the referenced organisation object.

Technically this would not be hard for RIPE NCC, but I fully appreciate that a schema change like this has potential big impact on users. That said, if there are many cases where there is no clear case for a "descr:" that is not the organisation name, then this may not be a bad option. Leaving this mandatory would then lead to descr content that is not very useful.


Option c: Clean up existing cases, "descr:" mandatory, update request forms
===========================================================================
A compromise: leave "descr:" mandatory, do a clean up, but leave a placeholder "descr:" in cases where no "descr:" would be left - describing all this, and encouraging the actual holder to update it. Accept that some of those will remain in objects for a very long time. And in this case request forms and processes still need to be updated to ensure that some "descr:" is provided.

This approach would have less impact on users (scripts) that rely on parsing inet6num and aut-num objects, but it may well lead to a lot of "descr:" lines that don't contain useful information.

I hope that it's clear from the above that we are committed to stopping enforcing, but we're looking for the best way to actually achieve this. If you have a preference for any of these approaches or see another way I would love to hear your feedback. 


Kind regards,

Tim Bruijnzeels

Assistant Manager Software Engineering
RIPE NCC