<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style> </head> <body dir="ltr"> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Focus Porland, than you will see.</div> <div id="appendonsend"></div> <hr style="display:inline-block;width:98%" tabindex="-1"> <div id="divRplyFwdMsg" dir="ltr">From: db-wg <db-wg-bounces@ripe.net> on behalf of Ronald F. Guilmette via db-wg <db-wg@ripe.net> Sent: Monday, September 6, 2021 11:42 PM To: Database WG <db-wg@ripe.net> Subject: Re: [db-wg] Cosmetic changes to the RIPE Database <div> </div> </div> <div class="BodyFragment"> <div class="PlainText">In message <CAKvLzuEOF2TTkEQgfEXwT6gdV2S2autBbZUubn4idanXYeCYxw@mail.gmail.com> denis walker <ripedenis@gmail.com> wrote: >There have been a number of cosmetic changes to the RIPE Database in >recent months. There is no agreed procedure for making these type of >changes. In particular the extent to which the community is informed. >Examples of the type of changes we are talking about are: >1/ When the ORGANISATION object addresses were synced with the >internal registry the address lines were entered in the wrong order. >The RIPE NCC did a cosmetic update to reverse the order of the address >lines. It had no operational impact at all. >2/ Capitalisation of status values. Again this had no operational impact at all. I am in agreement 100% that these all constitute "cosmetic" changes. In fact, this gives me an excuse to bring up another such "cosmetic" change that I proposed some time back and that was met with stony silence from everyone here, to wit: All case-insensitive handles appearing in the data base should be forced to all upper case. I seem to recall that at some point in time, on this list, at least one person did suggest that perhaps it would be Nice if such "cosmetic" aspects of the data base were done in a manner that would simplify parsing of data base elements. Speaking as one who routinely is engaged in the parsing of data base elements I vigorously agree with that sentiment. The current status quo in which case-insensitive handles appear in the data base with all sort of bizzare semi-capitalizations serves no purpose other than to confuse all users into the mistaken belief that case has some actual and practical significance when it comes to handles, when in fact it does not. Furthermore it is unambiguously the case that the lack of consistant capitalization of handles in the data base needlessly complicates parsing and any kind of automated analysis. What is the practical usefulness of this "cosmetic" foolishness? If there is none, then can we please get rid of it? It generates needless additional complaxity for *zero* practical gain. >We would like some feedback from the community about how you want >these type of cosmetic changes announced. We see four possible >options: > >1/ individual notification in advance to all affected maintainers plus >general announcement on the mailing list plus update notifications >(full disclosure) >2/ general announcement on the mailing list plus update notifications >3/ general announcement on mailing list and silent update (no notifications) >4/ no announcement, no notifications, just do it without disturbing >anyone (totally silent) It is not clear from the foregoing what you mean by "notifications" as contrasted with "individual notifications". Can you please elaborate denis? In any event, my personal answer to your question is that there exists both a DB WG working group mailing list and also a member's announcements mailing list, and if members want to keep abreast of such events and changes, they should be subscribed to one or the other of those lists, and thus, it should be sufficient just to make the cosmetic change after pre-announcing it on these mailing lists. I certainly don't see why any individualized member notifications would be either helpful or necessary. Regards, rfg </div> </div> </body> </html>