[db-wg] Implementation proposal descr line

Hi Tim,

For the record, I have long used the existing "netname:" format as a shortcut to infer the regid of an allocation, without resorting to parsing alloclist.txt, although of course this only really worked for PA allocations. The use of "org:" and "sponsoring-org:" has partially offset this, but not entirely.

Having said that, I'm not heavily opposed to a change. It would be useful to know what the actual pros and cons of each option is perceived to be.

Thanks,

Ian

-----Original Message-----
From: db-wg [mailto:db-wg-bounces at ripe.net] On Behalf Of Tim Bruijnzeels
Sent: 27 January 2016 16:28
To: Database WG
Subject: Re: [db-wg] Implementation proposal descr line

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.


Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.