all looks good to me. Nick On 23/10/2015 15:38, Shane Kerr wrote:

Tim,

On Tue, 20 Oct 2015 12:23:02 +0200 Tim Bruijnzeels <tim@ripe.net> wrote:

...

Implementation proposal: ========================

= Change "descr:" to an 'optional multiple' attribute

Makes sense.

...

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.

Yes.

...

Because this can have an impact on automated systems the RIPE NCC will announce this change ncc-announce@ripe.net, and use a longer week staging period in the Release Candidate environment allowing users to test and update their systems.

Reasonable, although I'm sure most users will discover this only after the first object without a "descr:" attribute appears and their scripts explode in colorful ways. ;)

...

= 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.

I have no strong preference here. I don't see a huge motivation for the removal, but I'm not against this.

...

= Add "descr:" to allocation object editor in LIR Portal

So that LIRs can edit this themselves.

Makes sense.

...

= 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.

Presumably a blank "descr:" does not get added to the object?

Cheers,

-- Shane

-- Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 5313339 52 Lower Sandwith St | INEX - Internet Neutral | Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie

Dear working group, On 14 Jan 2016, at 17:54, Job Snijders <job@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).

Same as the RPSL maintainer (other thread) I expect that we can start work on this in February. But I can communicate a more detailed plan at the beginning of next week. Kind regards, Tim Bruijnzeels

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@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.

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@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@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@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.

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@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@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@artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

Am 28.01.16 um 15:45 schrieb Sascha Luck [ml]:

On Thu, Jan 28, 2016 at 12:03:49PM +0100, Andreas Worbs wrote:

...

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.

AIUI, this affects only allocation and independent resource assignment objects. An object of this type without an "org:" field should not exist (Tim, correct me if I'm wrong).

For customer assignments, the "netname:" is filled in by the LIR and it's a freeform string so not a mandatory format.

AHH, that's my fault. I didn't realized it is about the allocations only. So i agree and the netname for the allocations can be cleaned.

...

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.

That's nearly the worst option, it would lead to an inconsistent format for these objects, some with "netname:", some without...

If it's optional you'll have the same situation. Some allocations will have a netname and some not. But because i didn't realized it's about the allocations only. It's not important for me anymore, i thought it's about cleaning up the assignment netnames :-)

rgds, Sascha Luck

-- 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@artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

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@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@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@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.