Dear Akil Evlat, When the change was discussed in this working group, it was concluded that this change should not affect any routing operations. And indeed, after we modified just over 93 thousand resource objects we received not a single report about operational issues. We rolled this change back because of issues with whitespace and a concern raised that a warning should have gone out to ncc-announce, but it's important to note that as far as we can tell there were indeed no operational issues affecting *routing*. Where this would affect operations is w.r.t. to look ups. I believe your allocation objects currently only have one "descr:" entry with your organisation name. So in your case the clean-up would mean that your allocation objects would have no remaining "descr:" attribute, but do keep a reference to your organisation through the "org:". So people doing ad-hoc lookups, or tools that show the organisation associated with a resource should now follow the reference to the organisation object instead. This is good advice in general because the "descr:" attribute may be blank, as it's now optional (even without the clean-up), or it may have something that looks like an organisation name - but it's not kept in sync with the organisation name that the RIPE NCC verifies, and in case of more specific int(6)num objects under allocations or legacy objects it can contain any text entered by the holder of the object. So in short: it has never been possible to trust that "descr:" has the organisation name for all resource objects in the database, even more so now that users can modify it for allocations and assignments done through RIPE NCC. Kind regards, Tim Bruijnzeels
On 22 Apr 2016, at 09:49, AKIL EVLAT <AKIL.EVLAT@kktcell.com> wrote:
Hi,
From what i understand no changes are going to be made that effects users and no actions have to be taken by the users.
But as KKTCELL we would like to know what will the name/abbreviaton change to. What will be the new abbreviations?
Are any of the users going to be effected in any way? Or is there such a risk?
Kind Regards,
AKIL EVLAT KUZEY KIBRIS TURKCELL | KKTCELL TECHNICAL OPERATIONS | PACKET NETWORK SPECIALIST Bedreddin Demirel Cad. Salih Mecit Sok. No:1 PO 883 Lefkoşa / KKTC T: +90 533 850 0175 E: akil.evlat@kktcell.com
-----Original Message----- From: ncc-announce [mailto:ncc-announce-bounces@ripe.net] On Behalf Of Tim Bruijnzeels Sent: Tuesday, April 19, 2016 5:17 PM To: ncc-announce@ripe.net Subject: [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
Dear colleagues,
We want to let you know about a clean-up that we have been planning with the RIPE Database Working Group (WG) and explain why this is being done. As this is currently being discussed on the WG mailing list, there is still time to comment if you wish.
Background ----------------
For a long time, there has been a requirement that the first "descr:" attribute of resource objects that were allocated/assigned by the RIPE NCC must match the name of the organisation that holds the resource. However, these resource objects have also had a reference to the organisation object of the holder of these resources for quite some time, and the RIPE NCC ensures that this organisation object matches what we have in the RIPE Registry. This means that we have been using two parallel approaches to achieve the same goal.
Since we began using organisation objects, requiring the organisation name in the “descr:” attribute has become redundant. It creates the potential for a mismatch between the name recorded here and the name on the actual organisation object. It also leads to confusion about where the correct name of the organisation can be found, along with a number of other issues.
This has been discussed at length on the RIPE Database WG mailing list and during WG sessions at RIPE 70, 71 and 72. Consensus was reached that going forward: - Organisation names should no longer be enforced in "descr:" attributes - LIRs should be allowed to modify the "descr:” attribute[1] and will be responsible for maintaining this (it will not be verified by the RIPE NCC) - The RIPE NCC should clean up existing cases where the organisation name is enforced - "descr:” should become an *optional* attribute
Last Week’s Reverted Clean-up ------------------------------------------
The WG decided that a clean-up was needed to remove any confusion about where the organisation name should be found. Because there are 93,105 objects that need to be updated, it is not practical to send notifications to all of these resource holders individually. As this change was expected to have little operational impact, it was decided that this should be done as a silent update. However, while the WG was informed of our intention to run the clean-up, it was an oversight on our part not to send a notification to the wider RIPE community.
We proceeded with our implementation of these changes in the RIPE Database and deployed release 1.86 to production on 21 March. We then communicated our intent to run the clean-up on 11 April to the Database WG[2]. When we ran the update last week, a community member alerted us to a problem and the clean-up was reverted the following day after it was completed[3].
There is now a discussion about how or whether to continue with this clean-up on the RIPE Database WG mailing list[4]. If the WG determines that we should proceed with this, we have a tentative date set for 9 May 2016. We invite you to discuss this further on the mailing list at <db-wg@ripe.net> if you have any opinions or concerns that you would like to share.
We will also be reviewing our processes to ensure we give adequate notification for such changes in the future.
Kind regards,
Tim Bruijnzeels
Assistant Manager Software Engineering RIPE NCC Database Group
[1] "descr:" is currently not editable in the Allocation Object Editor, but will become editable by LIRs in the near future. [2] https://www.ripe.net/ripe/mail/archives/db-wg/2016-March/005136.html [3] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005172.html [4] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005173.html
[http://www.kktcell.com/e-fatura/Disclaimer_Banner.jpg]<http://www.kktcell.com>
Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir.KUZEY KIBRIS TURKCELL bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve KUZEY KIBRIS TURKCELLin goruslerini yansitmayabilir
Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir.
________________________________
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted.KUZEY KIBRIS TURKCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of KUZEY KIBRIS TURKCELL.
This e-mail has been scanned for all known computer viruses.