[db-wg] Implementation proposal descr line

Dear working group,

After discussing this with the working group chairs it was decided that the best cause of action would be let working group discuss the future of "netname:", and in the meantime proceed with the "descr:" clean-up as proposed earlier.

We are currently working on an implementation consisting of two parts:
= Make "descr:" an optional multi-line attribute
= Clean up existing "descr:" that RIPE NCC has been enforcing

We plan to deploy release 1.86 for this to the Release Candidate environment on Wednesday 2 March.
Provided no issues are found we plan to deploy this version to production on Monday 21 March.

We will inform the working group again when we do these deployments.

Kind regards,

Tim Bruijnzeels

Assistant Manager Software Engineering
RIPE NCC Database Group


> On 28 Jan 2016, at 17:38, Tim Bruijnzeels <tim at ripe.net> wrote:
> 
> Dear working group,
> 
> Please allow me to clarify a few things.
> 
> First of all we are suggesting this now, because there may be an opportunity to combine this work with the intended cleanup of "descr:". However, if this proves controversial or requires more discussion then we have no problem with finishing the "descr:" clean up first.
> 
> The RIPE NCC enforces the "netname:" attribute for allocation objects only, for PI assignments and AS number assignments the attribute is currently editable by users.  Given that the "netname:" attribute is not enforced for these resources it may be out of sync with the name recorded in the organisation object which has implications for data quality.
> 
> The proposed cleanup would only apply to inetnum objects for allocations done by the RIPE NCC. So, in response to the comment Andreas made: this would not affect "netname:" attributes used on more specific assignment for customers.
> 
> Finally a subtlety about the dates used in "netname:". The dates here reflect the date of issuance of the resource. That means that if a resource is transferred, the original date is kept. In that it may be different from the "created:" date that reflects when the object was created. The date of first issuance of all resources can also be found in the extended delegated statistics published here: http://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest
> 
> However, if it is important that the date of issuance is also visible in the RIPE Database, then we would suggest that we automatically update the "created:" attribute for resources allocated or issued by the RIPE NCC to reflect the same date that can be found in the statistics file.
> 
> We hope that this makes it more clear.
> 
> Kind regards,
> 
> Tim Bruijnzeels
> 
>> On 27 Jan 2016, at 17:27, Tim Bruijnzeels <tim at ripe.net> wrote:
>> 
>> Dear working group,
>> 
>> We expect that we can implement this as part of the 1.86 release of the DB. We should be able to deploy this to the RC environment by Wednesday 2 March. And can then deploy to production on Monday 21 March.
>> 
>> However, we realised that a similar reasoning could also be applied to the "netname:" and "asname:" attributes that the RIPE NCC has been maintaining. A "netname:" for an inetnum (allocation) object is built up using the regid of the member, and the allocation date. However, since there is an "org:" reference and a "created:" attribute on the object this is redundant.
>> 
>> So before implementing the cleanup of "descr:" we would like to verify the following options with the working group:
>> 
>> 
>> 1) RIPE NCC cleans up, and the attributes become optional
>> 
>> In this scenario "netname:" and "asname:" would become optional. And a one time effort is done to remove the attribute where it has been enforced so-far.
>> This is our preferred option because not having duplicate possibly inconsistent data will improve data quality and reduce work.
>> 
>> We are not aware that either attribute has great operational value today, but this is something we would like to verify. So, please speak up if you see any operational or other concerns with this option.
>> 
>> If this option has consensus it would make sense to do this together with the cleanup of "descr:", and we avoid updating objects more often than necessary.
>> 
>> 
>> 2) RIPE NCC stops maintaining, and the attributes become user modifiable
>> 
>> Alternatively we could leave these attributes as mandatory, but allow users to change them - without any clean-up of existing cases. We can then also add this to resource request forms so that future objects can have a value specified by the member.
>> 
>> 
>> 3) RIPE NCC continues maintaining, and the attributes cannot be modified by the user
>> 
>> In this case we just keep doing what we have been doing so-far.
>> 
>> 
>> 
>> 
>> Kind regards,
>> 
>> Tim Bruijnzeels
>> 
>> Assistant Manager Software Engineering
>> RIPE NCC Database Group
>> 
>> 
>> 
>>> On 14 Jan 2016, at 17:54, Job Snijders <job at instituut.net> wrote:
>>> 
>>> Dear Working group, RIPE NCC,
>>> 
>>> Support was shown for this proposal and no objections were raised after
>>> this round of discussion.
>>> 
>>> I asked RIPE NCC schedules implementation of this plan as proposed by
>>> Tim (keeping in mind Shane's comment about empty "descr:" attributes).
>>> 
>>> Thank you all for your time reviewing this!
>>> 
>>> Kind regards,
>>> 
>>> Job Snijders
>>> DB-WG Chairs
>>> 
>>> On Tue, Oct 20, 2015 at 12:23:02PM +0200, Tim Bruijnzeels wrote:
>>>> Dear working groups,
>>>> 
>>>> Following discussion in this group it was decided that the RIPE NCC
>>>> should stop enforcing that the first "descr:" attribute of resource
>>>> objects reflects the name of the organisation, for resources that it
>>>> alloced or assigned. This practice has been place for a long time, but
>>>> now that all such objects have a reference to an organisation object
>>>> and the RIPE NCC ensures that this reflects the resource requests,
>>>> this is no longer needed.
>>>> 
>>>> Furthermore it was decided that the RIPE NCC should clean up existing
>>>> organisation names in "descr:" attributes in order to:
>>>> (1) avoid confusion about where the organisation name should be found;
>>>> (2) avoid that the names here are different from the name of the actual organisation;
>>>> (3) make it very clear which attributes are verified by RIPE NCC, and which attributes are not.
>>>> 
>>>> Hereby the RIPE NCC would like to propose an implementation plan for
>>>> these changes. We invite the working group to review and discuss if
>>>> needed. As soon as the working group co-chairs formally call
>>>> consensus, we can proceed to implement shortly.
>>>> 
>>>> Implementation proposal:
>>>> ========================
>>>> 
>>>> = Change "descr:" to an 'optional multiple' attribute
>>>> 
>>>> We believe that the working group concluded that it would be
>>>> appropriate to make "descr:" optional. The reason is that when the
>>>> organisation name is cleaned up, there may be no description lines
>>>> left. The working group considered whether the attribute should be
>>>> 'single optional', but there seemed to be no strong preference for
>>>> this, and it would have a bigger impact. Therefore we propose to go
>>>> for the easier option of making it 'optional multiple'.
>>>> 
>>>> Technically this change is not hard to do on the server side, but can
>>>> impact users of the database because there may be no "descr:"
>>>> attribute, and this can affect parsers.
>>>> 
>>>> Because this can have an impact on automated systems the RIPE NCC will
>>>> announce this change ncc-announce at ripe.net, and use a longer week
>>>> staging period in the Release Candidate environment allowing users to
>>>> test and update their systems.
>>>> 
>>>> Dependent on formal consensus call we may be able to combine this with
>>>> the upcoming release for deprecating "changed:" phase 3, to avoid
>>>> delays.
>>>> 
>>>> = Clean up existing "descr:" attributes where RIPE NCC enforced the organisation name
>>>> 
>>>> The RIPE NCC will remove the "descr:" attributes that it has been enforcing.
>>>> 
>>>> = Add "descr:" to allocation object editor in LIR Portal
>>>> 
>>>> So that LIRs can edit this themselves.
>>>> 
>>>> = Stop setting the "descr:" on new allocations or assignments done by the RIPE NCC
>>>> 
>>>> We will leave "descr:" blank. It can be edited by the LIR or end-user later.
>> 
>> 
> 
>