Re: [db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
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.
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.
On 2016 Apr 25 (Mon) at 14:03:32 +0200 (+0200), Tim Bruijnzeels wrote: :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. As one who did report issues, I must disagree. We can debate what "operational issues" mean, but my objects having a new "name" on various 3rd party services _is_ an issue that is a problem. We set those entries with care. Hell, (let's bring up something older) we even used changed: correctly! (side note: changed: could have ALSO been used for us to understand why this changed happened) A number of people are very concerned that their objects will be modified without concern that these values have been chosen on purpose. What is the criteria for selecting which objects will be changed? Not set to the previous default? Multiple lines? :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*. : Is *routing* the only thing that the database cares about? If that's true, there is a lot of things I can stop doing in the database, and all sorts of objects that can be deleted. Is that really what you are saying? :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 : -- Avoid Quiet and Placid persons unless you are in Need of Sleep. -- National Lampoon, "Deteriorata"
Hi Thanks for the reply. 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: Peter Hessler [mailto:phessler@theapt.org] Sent: Monday, April 25, 2016 3:35 PM To: Tim Bruijnzeels <tim@ripe.net> Cc: AKIL EVLAT <AKIL.EVLAT@kktcell.com>; db-wg@ripe.net; TO-CO-PN <TO-CO-PN@kktcell.com>; ncc-announce@ripe.net; BARIS KIZILDERE <BARIS.KIZILDERE@kktcell.com> Subject: Re: [db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:" On 2016 Apr 25 (Mon) at 14:03:32 +0200 (+0200), Tim Bruijnzeels wrote: :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. As one who did report issues, I must disagree. We can debate what "operational issues" mean, but my objects having a new "name" on various 3rd party services _is_ an issue that is a problem. We set those entries with care. Hell, (let's bring up something older) we even used changed: correctly! (side note: changed: could have ALSO been used for us to understand why this changed happened) A number of people are very concerned that their objects will be modified without concern that these values have been chosen on purpose. What is the criteria for selecting which objects will be changed? Not set to the previous default? Multiple lines? :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*. : Is *routing* the only thing that the database cares about? If that's true, there is a lot of things I can stop doing in the database, and all sorts of objects that can be deleted. Is that really what you are saying? :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 : -- Avoid Quiet and Placid persons unless you are in Need of Sleep. -- National Lampoon, "Deteriorata" [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.
Dear Peter, wg, On 25 Apr 2016, at 14:35, Peter Hessler <phessler@theapt.org> wrote:
On 2016 Apr 25 (Mon) at 14:03:32 +0200 (+0200), Tim Bruijnzeels wrote: :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.
As one who did report issues, I must disagree.
We can debate what "operational issues" mean, but my objects having a new "name" on various 3rd party services _is_ an issue that is a problem.
We set those entries with care. Hell, (let's bring up something older) we even used changed: correctly! (side note: changed: could have ALSO been used for us to understand why this changed happened)
A number of people are very concerned that their objects will be modified without concern that these values have been chosen on purpose.
What is the criteria for selecting which objects will be changed? Not set to the previous default? Multiple lines?
I was referring to issues related to routing, as I hoped would be clear from the continuation of the paragraph. Let me get back to the other point you raise here at the end of this email.
: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*. :
Is *routing* the only thing that the database cares about? If that's true, there is a lot of things I can stop doing in the database, and all sorts of objects that can be deleted.
Is that really what you are saying?
No, all I am saying is that it's important to point out that this working group thought about any potential impact on routing, came to conclusion that routing should not be affected, and this is confirmed by the change that was rolled back. Other than the issues reported by you regarding whitespace and contact information in third party tools, we received no tickets.
: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.
It was definitely not the case that routing was the only concern. Data quality and clarity on where to find information were precisely why a clean-up was intended. The criteria for clean-up were discussed in this working group. Those "descr:" attributes that have been enforced by RIPE NCC were to be cleaned-up, so that it would be clear that a) this is NOT the place to look for the authoritative organisation name, and b) this is no longer enforced by RIPE NCC (as required by the community). Third party tools that assume that the "descr:" attribute refers to the organisation name will find that this assumption does not hold up in general. Even without a clean-up this is something that may become modified to something else completed, or outdated w.r.t. the organisation name verified by RIPE NCC. Furthermore the assumption has never been true for assignments done by LIRs and resources held by legacy holders. So, regardless of whether the clean-up is actually done, third party tools *should* look for an associated organisation object (possibly higher in the hierarchy*). For example, Alex recently had contact with Hurricane Electric and they are now changing their implementation along these lines. As I mentioned in a previous email, these concerns were discussed in this working group. And at the time there was consensus to go-ahead with a clean up. That being said I also made it clear in that email that in the light of recent discussions we are looking at the working group to decide on how to move forward, and we will only run the clean-up again after a consensus is called again by the co-chairs. *: BTW. Regardless of whether a clean-up is done, we can implement something to show the actual organisation name when a resource is looked up - similar to how we now show abuse contact information with resources. Kind regards, Tim Bruijnzeels
: : :Kind regards, : :Tim Bruijnzeels :
-- Avoid Quiet and Placid persons unless you are in Need of Sleep. -- National Lampoon, "Deteriorata"
Hi Peter, Tim On 25/04/2016 16:19, Tim Bruijnzeels wrote:
Dear Peter, wg,
On 25 Apr 2016, at 14:35, Peter Hessler <phessler@theapt.org> wrote:
We set those entries with care. Hell, (let's bring up something older) we even used changed: correctly! (side note: changed: could have ALSO been used for us to understand why this changed happened)
A number of people are very concerned that their objects will be modified without concern that these values have been chosen on purpose.
What is the criteria for selecting which objects will be changed? Not set to the previous default? Multiple lines?
Other than the issues reported by you regarding whitespace and contact information in third party tools, we received no tickets.
It was definitely not the case that routing was the only concern. Data quality and clarity on where to find information were precisely why a clean-up was intended.
The criteria for clean-up were discussed in this working group. Those "descr:" attributes that have been enforced by RIPE NCC were to be cleaned-up, so that it would be clear that a) this is NOT the place to look for the authoritative organisation name, and b) this is no longer enforced by RIPE NCC (as required by the community).
Third party tools that assume that the "descr:" attribute refers to the organisation name will find that this assumption does not hold up in general. Even without a clean-up this is something that may become modified to something else completed, or outdated w.r.t. the organisation name verified by RIPE NCC. Furthermore the assumption has never been true for assignments done by LIRs and resources held by legacy holders. So, regardless of whether the clean-up is actually done, third party tools *should* look for an associated organisation object (possibly higher in the hierarchy*). For example, Alex recently had contact with Hurricane Electric and they are now changing their implementation along these lines.
As I mentioned in a previous email, these concerns were discussed in this working group. And at the time there was consensus to go-ahead with a clean up. That being said I also made it clear in that email that in the light of recent discussions we are looking at the working group to decide on how to move forward, and we will only run the clean-up again after a consensus is called again by the co-chairs.
Which illustrates why these old fashioned emailing lists are not the best way to gather a consensus. Out of the 12k+ members (plus other database users) only a handful ever comment on anything on these lists. At the moment it is the only way to get any consensus but it is not a representative view.
*: BTW. Regardless of whether a clean-up is done, we can implement something to show the actual organisation name when a resource is looked up - similar to how we now show abuse contact information with resources.
This would be a good idea. I have been saying for many years the RIPE NCC or DB WG should investigate what third party tools are commonly used by database users, what these tools do and add commonly used functionality to the database software tool set. There are many third party tools used for covering the three main functions of the database, number registry, routing registry and reverse delegation facilitation. With or without any data model changes, the RIPE Database should be seen as something that provides information rather than raw data. As Tim said, using tools like the Abuse Finder or RIPEstat the correct information will always be returned regardless of the internal structure or storage of raw data. cheers denis
Kind regards, Tim Bruijnzeels
: : :Kind regards, : :Tim Bruijnzeels :
-- Avoid Quiet and Placid persons unless you are in Need of Sleep. -- National Lampoon, "Deteriorata"
participants (4)
-
AKIL EVLAT -
denis -
Peter Hessler -
Tim Bruijnzeels