Cosmetic changes to the RIPE Database
Colleagues 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. 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) Some points to note: -In all cases the object history will show the changes. -There is also an option to not change the "last-modified:" attribute if you don't want that to reflect cosmetic changes. -The full disclosure option (1) can sometimes lead to considerable extra work load for the RIPE NCC. If people are individually told in advance of a change they don't always realise it has no operational impact and ask questions. Every question opens a ticket that needs to be manually addressed. -Perhaps options 2 or 3 are the most practical? Your feedback is welcomed... cheers denis co-chair DB-WG
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
Focus Porland, than you will see. ________________________________ 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 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
Hi Ronald Just to clarify what we mean by notifications. 'individual notification in advance' - means sending an email to the contacts of the MNTNER objects of all the objects to be updated by the cosmetic change before the change takes place 'update notifications' - these are the notification emails sent out by the update software, when a change takes place, to the "notify:" and "mnt-nfy:" attribute email addresses cheers denis co-chair DB-WG On Mon, 6 Sept 2021 at 22:42, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
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
Colleagues We had one comment on this. Does anyone else have an opinion? cheers denis co-chair DB-Wg On Mon, 6 Sept 2021 at 15:19, denis walker <ripedenis@gmail.com> wrote:
Colleagues
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.
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)
Some points to note: -In all cases the object history will show the changes. -There is also an option to not change the "last-modified:" attribute if you don't want that to reflect cosmetic changes. -The full disclosure option (1) can sometimes lead to considerable extra work load for the RIPE NCC. If people are individually told in advance of a change they don't always realise it has no operational impact and ask questions. Every question opens a ticket that needs to be manually addressed. -Perhaps options 2 or 3 are the most practical?
Your feedback is welcomed...
cheers denis co-chair DB-WG
Hi, I would prefer option 3 but option 2 is also fine imo. -Cynthia On Wed, Sep 15, 2021, 17:28 denis walker via db-wg <db-wg@ripe.net> wrote:
Colleagues
We had one comment on this. Does anyone else have an opinion?
cheers denis co-chair DB-Wg
On Mon, 6 Sept 2021 at 15:19, denis walker <ripedenis@gmail.com> wrote:
Colleagues
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.
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)
Some points to note: -In all cases the object history will show the changes. -There is also an option to not change the "last-modified:" attribute if you don't want that to reflect cosmetic changes. -The full disclosure option (1) can sometimes lead to considerable extra work load for the RIPE NCC. If people are individually told in advance of a change they don't always realise it has no operational impact and ask questions. Every question opens a ticket that needs to be manually addressed. -Perhaps options 2 or 3 are the most practical?
Your feedback is welcomed...
cheers denis co-chair DB-WG
participants (4)
-
Cynthia Revström
-
denis walker
-
Elad Cohen
-
Ronald F. Guilmette