[db-wg] Implementation proposal descr line

Hi Tim,

i think a forced clean-up for everbodies "netname" and "asname" is not
the right way at the moment. At the one hand the netname is very useful
for a quick lookup and general view of your subnets and at the other
hand "org:" is optional at the moment and not everybody had set up an
"org:". So after a forced deleting of "netname:" it is possible that you
don't have an information in the WHOIS to which customer the subnet
belongs to.
I think it is the right way if "netname:" becomes optional and everybody
can consider if they want to delete "netname:" themselves or perhaps
through RIPE. Don't know if it's possible to set up an option in the LIR
portal and the LIR can set a flag until DD-MM-YYYY if RIPE shall
clean-up their netname attributes.

If i misunderstood option 1 i will feel ashamed and you can forget my
remarks :-[

Am 27.01.16 um 17:27 schrieb Tim Bruijnzeels:
> 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.
>

-- 
Mit freundlichem Gruß

Artfiles New Media GmbH

Andreas Worbs


Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg
Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95
E-Mail: support at artfiles.de | Web: http://www.artfiles.de
Geschäftsführer: Harald Oltmanns | Tim Evers
Eingetragen im Handelsregister Hamburg - HRB 81478


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 522 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/db-wg/attachments/20160128/65b742f8/attachment.sig>