NCC still enforcing descr: content
Hello Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I’m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is: https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html Quote: ----------------------------------------------------------- "> When will this change go into effect? We were thinking of mid April, for two reasons: 1) This gives the working group enough time to comment. 2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." ----------------------------------------------------------- I personally know a case where the NCC went as far as to ignore German “umlauts” in the name and deliberately spell it wrong in the descr: field of the guy’s AUT-NUM object. When he tried to set it right (ae (ä) instead of a), the NCC reverted the change. Then there’s a case where someone tried to remove his middle name from the descr: field —> reverted. Another post on the same subject: https://www.ripe.net/ripe/mail/archives/members-discuss/2015-June/001737.htm... Looks like there’s still a lot of energy wasted in those descr fields now that the org pointer is mandatory. Cheers
Dear Jan, Working Group,
On Jul 27, 2015, at 6:41 PM, Jan Saner <jan@trick77.com> wrote:
Hello
Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I’m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is:
https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html
Quote: ----------------------------------------------------------- "> When will this change go into effect?
We were thinking of mid April, for two reasons:
1) This gives the working group enough time to comment.
2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." -----------------------------------------------------------
Well, in short I misjudged the effort needed for this, and since then I presented an update on this at the RIPE meeting, see slide 4 here: https://ripe70.ripe.net/wp-content/uploads/presentations/164-ripe70-db-wg-ne... We are *nearly* done. We have a bit over 100 aut-num objects to work on (as compared to 2000 in May). When this is fully done, we can present an implementation plan for this soon, within a few weeks. Before we do so, I would like to ask the working group for direction on the following. Because sadly, stopping enforcing this is not as trivial as it might seem. Option a: Leave existing cases, "descr:" mandatory, update request forms ======================================================================== We would leave existing cases, but note that this can lead to confusion because the names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line. We would also need to change request forms and processes to make sure that a sensible description is provided (i.e. not the name). This would take some time to implement, but can be done if this is where we need to go. Option b: Clean up existing cases, "descr:" optional ===================================================== On the other hand if "descr:" could be optional, we would be able to do a bulk change to remove the existing organisation names from the "descr:" of objects, both for end-user resources as well as for allocations. And then leave it to the holders of these objects to modify as they please. This would be the cleanest in the sense that any remaining "descr:" would be fully maintained by the resource holders, and the one place to look for the organisation name is in the referenced organisation object. Technically this would not be hard for RIPE NCC, but I fully appreciate that a schema change like this has potential big impact on users. That said, if there are many cases where there is no clear case for a "descr:" that is not the organisation name, then this may not be a bad option. Leaving this mandatory would then lead to descr content that is not very useful. Option c: Clean up existing cases, "descr:" mandatory, update request forms =========================================================================== A compromise: leave "descr:" mandatory, do a clean up, but leave a placeholder "descr:" in cases where no "descr:" would be left - describing all this, and encouraging the actual holder to update it. Accept that some of those will remain in objects for a very long time. And in this case request forms and processes still need to be updated to ensure that some "descr:" is provided. This approach would have less impact on users (scripts) that rely on parsing inet6num and aut-num objects, but it may well lead to a lot of "descr:" lines that don't contain useful information. I hope that it's clear from the above that we are committed to stopping enforcing, but we're looking for the best way to actually achieve this. If you have a preference for any of these approaches or see another way I would love to hear your feedback. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
On Tue, Jul 28, 2015 at 06:01:29PM +0200, Tim Bruijnzeels wrote:
On Jul 27, 2015, at 6:41 PM, Jan Saner <jan@trick77.com> wrote: Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I’m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is:
https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html
Well, in short I misjudged the effort needed for this, and since then I presented an update on this at the RIPE meeting, see slide 4 here: https://ripe70.ripe.net/wp-content/uploads/presentations/164-ripe70-db-wg-ne...
We are *nearly* done. We have a bit over 100 aut-num objects to work on (as compared to 2000 in May).
When this is fully done, we can present an implementation plan for this soon, within a few weeks. Before we do so, I would like to ask the working group for direction on the following. Because sadly, stopping enforcing this is not as trivial as it might seem.
Option a: Leave existing cases, "descr:" mandatory, update request forms ========================================================================
Option A sounds simplest to me, I am confident people will continue to update the "descr:" to align it with reality in a meaningful way. Kind regards, Job
Hello Tim, Like Job, I’d also appreciate option A. Cheers, Jan
On 28 Jul 2015, at 18:01, Tim Bruijnzeels <tim@ripe.net> wrote:
Dear Jan, Working Group,
On Jul 27, 2015, at 6:41 PM, Jan Saner <jan@trick77.com> wrote:
Hello
Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I’m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is:
https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html
Quote: ----------------------------------------------------------- "> When will this change go into effect?
We were thinking of mid April, for two reasons:
1) This gives the working group enough time to comment.
2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." -----------------------------------------------------------
Well, in short I misjudged the effort needed for this, and since then I presented an update on this at the RIPE meeting, see slide 4 here: https://ripe70.ripe.net/wp-content/uploads/presentations/164-ripe70-db-wg-ne...
We are *nearly* done. We have a bit over 100 aut-num objects to work on (as compared to 2000 in May).
When this is fully done, we can present an implementation plan for this soon, within a few weeks. Before we do so, I would like to ask the working group for direction on the following. Because sadly, stopping enforcing this is not as trivial as it might seem.
Option a: Leave existing cases, "descr:" mandatory, update request forms ========================================================================
We would leave existing cases, but note that this can lead to confusion because the names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line.
We would also need to change request forms and processes to make sure that a sensible description is provided (i.e. not the name). This would take some time to implement, but can be done if this is where we need to go.
Option b: Clean up existing cases, "descr:" optional ===================================================== On the other hand if "descr:" could be optional, we would be able to do a bulk change to remove the existing organisation names from the "descr:" of objects, both for end-user resources as well as for allocations. And then leave it to the holders of these objects to modify as they please. This would be the cleanest in the sense that any remaining "descr:" would be fully maintained by the resource holders, and the one place to look for the organisation name is in the referenced organisation object.
Technically this would not be hard for RIPE NCC, but I fully appreciate that a schema change like this has potential big impact on users. That said, if there are many cases where there is no clear case for a "descr:" that is not the organisation name, then this may not be a bad option. Leaving this mandatory would then lead to descr content that is not very useful.
Option c: Clean up existing cases, "descr:" mandatory, update request forms =========================================================================== A compromise: leave "descr:" mandatory, do a clean up, but leave a placeholder "descr:" in cases where no "descr:" would be left - describing all this, and encouraging the actual holder to update it. Accept that some of those will remain in objects for a very long time. And in this case request forms and processes still need to be updated to ensure that some "descr:" is provided.
This approach would have less impact on users (scripts) that rely on parsing inet6num and aut-num objects, but it may well lead to a lot of "descr:" lines that don't contain useful information.
I hope that it's clear from the above that we are committed to stopping enforcing, but we're looking for the best way to actually achieve this. If you have a preference for any of these approaches or see another way I would love to hear your feedback.
Kind regards,
Tim Bruijnzeels
Assistant Manager Software Engineering RIPE NCC
Hi Tim et al, On 28.07.2015 18:01, Tim Bruijnzeels wrote:
Option a: Leave existing cases, "descr:" mandatory, update request forms ========================================================================
We would leave existing cases, but note that this can lead to confusion because the names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line.
We would also need to change request forms and processes to make sure that a sensible description is provided (i.e. not the name). This would take some time to implement, but can be done if this is where we need to go.
I like the part "Leave existing cases". Looking at different inetnums it seams good to have a "descr:" tag beside the "netname:", but I don't have a strong opinion on that. Cheers, Tim
Tim, option B seems like a cleaner long term fix. The org: name in the descr: field is currently well-structured and could be removed easily without affecting any of the other lines. After all, it was inserted by the RIPE NCC in a mass-db operation in the first place. Why is it troublesome to remove again, now that we have a proper fix in place, i.e. mandatory dependence on the org: object? Using descr: for mandatory information should never have been anything more than a short term workaround to a schema problem. Nick On 28/07/2015 17:01, Tim Bruijnzeels wrote:
Dear Jan, Working Group,
On Jul 27, 2015, at 6:41 PM, Jan Saner <jan@trick77.com> wrote:
Hello
Since the NCC still seems to heavy-handedly revert changes to descr: in AUT-NUM, INETNUM and INETNUM6 I’m wondering what the current status of the implementation mentioned by Tim in a post to this list from February is:
https://www.ripe.net/ripe/mail/archives/db-wg/2015-February/004496.html
Quote: ----------------------------------------------------------- "> When will this change go into effect?
We were thinking of mid April, for two reasons:
1) This gives the working group enough time to comment.
2) While the RIPE NCC has finished the effort to ensure that the org-id (and name) are set up correctly for all INETNUM and INET6NUM objects, we are still finalising this work for AUT-NUM objects. We expect that we will finish this effort in about 6 weeks. For consistency it would be easiest to change this for all resource types simultaneously." -----------------------------------------------------------
Well, in short I misjudged the effort needed for this, and since then I presented an update on this at the RIPE meeting, see slide 4 here: https://ripe70.ripe.net/wp-content/uploads/presentations/164-ripe70-db-wg-ne...
We are *nearly* done. We have a bit over 100 aut-num objects to work on (as compared to 2000 in May).
When this is fully done, we can present an implementation plan for this soon, within a few weeks. Before we do so, I would like to ask the working group for direction on the following. Because sadly, stopping enforcing this is not as trivial as it might seem.
Option a: Leave existing cases, "descr:" mandatory, update request forms ========================================================================
We would leave existing cases, but note that this can lead to confusion because the names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line.
We would also need to change request forms and processes to make sure that a sensible description is provided (i.e. not the name). This would take some time to implement, but can be done if this is where we need to go.
Option b: Clean up existing cases, "descr:" optional ===================================================== On the other hand if "descr:" could be optional, we would be able to do a bulk change to remove the existing organisation names from the "descr:" of objects, both for end-user resources as well as for allocations. And then leave it to the holders of these objects to modify as they please. This would be the cleanest in the sense that any remaining "descr:" would be fully maintained by the resource holders, and the one place to look for the organisation name is in the referenced organisation object.
Technically this would not be hard for RIPE NCC, but I fully appreciate that a schema change like this has potential big impact on users. That said, if there are many cases where there is no clear case for a "descr:" that is not the organisation name, then this may not be a bad option. Leaving this mandatory would then lead to descr content that is not very useful.
Option c: Clean up existing cases, "descr:" mandatory, update request forms =========================================================================== A compromise: leave "descr:" mandatory, do a clean up, but leave a placeholder "descr:" in cases where no "descr:" would be left - describing all this, and encouraging the actual holder to update it. Accept that some of those will remain in objects for a very long time. And in this case request forms and processes still need to be updated to ensure that some "descr:" is provided.
This approach would have less impact on users (scripts) that rely on parsing inet6num and aut-num objects, but it may well lead to a lot of "descr:" lines that don't contain useful information.
I hope that it's clear from the above that we are committed to stopping enforcing, but we're looking for the best way to actually achieve this. If you have a preference for any of these approaches or see another way I would love to hear your feedback.
Kind regards,
Tim Bruijnzeels
Assistant Manager Software Engineering RIPE NCC
-- 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
Hi,
option B seems like a cleaner long term fix.
I agree. I think leaving descr: mandatory will lead to confusion. Some descr: will refer to an organisation, some will not, some will refer to a different organisation than org:, and for new objects some content for descr: will have to be invented not because there is any useful information but just because the field is mandatory... If we clean this up I think we should do it properly. Cheers, Sander
On Mon, Aug 03, 2015 at 11:18:09PM +0200, Sander Steffann wrote:
option B seems like a cleaner long term fix.
I agree. I think leaving descr: mandatory will lead to confusion.
I disagree, the only confusion so far as been that that attribute's value cannot be a description but in the past had to be the 'proper' company name.
Some descr: will refer to an organisation, some will not, some will refer to a different organisation than org:, and for new objects some content for descr: will have to be invented not because there is any useful information but just because the field is mandatory...
If we clean this up I think we should do it properly.
To me the "descr:" attribute is an easy to parse component of an IRR object, there is only one "descr:" line, and it is mandatory according to RFC. If I look at organisations that have multiple ASNs the "descr:" attribute can be an informative hint which department or thingy you are dealing with. Semantically "descr:" is an easy place to look for a short summary of what the object is about. A parser can follow the "org:" object for a degree of legal validity, and use "descr:" for an informal, informative textual representation of what the object might be. Kind regards, Job
Hi Job and others First of all in all operational objects (INETNUM, INET6NUM, AUT-NUM, ROUTE) the "descr:" attribute is multiple. It was the value of the 'first' "descr:" attribute that was constrained to represent the organisation legal name. This was a crazy work around at the time. Trying to constrain a free text value to be fixed as a copy of another free text element. The reason this was dreamt up is because of the lack of inheritance in the data model. Also at the time the lack of confidence in positioning the ORGANISATION object at the centre of any database user's set of data and enforcing a reference to it. On 03/08/2015 23:50, Job Snijders wrote:
On Mon, Aug 03, 2015 at 11:18:09PM +0200, Sander Steffann wrote:
option B seems like a cleaner long term fix.
I agree. I think leaving descr: mandatory will lead to confusion.
I disagree, the only confusion so far as been that that attribute's value cannot be a description but in the past had to be the 'proper' company name.
This is not quite right. Only the first description line had to be the company name. Other descriptions could have been added and in many cases probably have been.
Some descr: will refer to an organisation, some will not, some will refer to a different organisation than org:, and for new objects some content for descr: will have to be invented not because there is any useful information but just because the field is mandatory...
If we clean this up I think we should do it properly.
To me the "descr:" attribute is an easy to parse component of an IRR object, there is only one "descr:" line, and it is mandatory according to RFC.
Not according to the RIPE Database implementation. It is a multiple attribute in all operational objects. When you say "easy to parse" I presume you mean by a human reading the data. Free text is never easy to parse by software.
If I look at organisations that have multiple ASNs the "descr:" attribute can be an informative hint which department or thingy you are dealing with. Semantically "descr:" is an easy place to look for a short summary of what the object is about.
A parser can follow the "org:" object for a degree of legal validity, and use "descr:" for an informal, informative textual representation of what the object might be.
Many objects probably already have these descriptions. So if you make it optional and remove the first "descr:" attribute, which is the one that was enforced to be a copy of the org name, then you have what you are asking for. cheers denis
Kind regards,
Job
On Tue, Aug 04, 2015 at 01:33:05AM +0200, denis wrote:
First of all [...]
Thank you for the historical context.
On 03/08/2015 23:50, Job Snijders wrote:
On Mon, Aug 03, 2015 at 11:18:09PM +0200, Sander Steffann wrote:
option B seems like a cleaner long term fix.
I agree. I think leaving descr: mandatory will lead to confusion.
I disagree, the only confusion so far as been that that attribute's value cannot be a description but in the past had to be the 'proper' company name.
This is not quite right. Only the first description line had to be the company name. Other descriptions could have been added and in many cases probably have been.
I stand corrected.
Some descr: will refer to an organisation, some will not, some will refer to a different organisation than org:, and for new objects some content for descr: will have to be invented not because there is any useful information but just because the field is mandatory...
If we clean this up I think we should do it properly.
To me the "descr:" attribute is an easy to parse component of an IRR object, there is only one "descr:" line, and it is mandatory according to RFC.
Not according to the RIPE Database implementation. It is a multiple attribute in all operational objects. When you say "easy to parse" I presume you mean by a human reading the data. Free text is never easy to parse by software.
Yes, I meant fit for human consumption (freetext), but easy to find for the parser. "descr:" to me is different then "remarks:", in general I found that "remarks:" is too elaborate while "descr:" is nicely terse.
If I look at organisations that have multiple ASNs the "descr:" attribute can be an informative hint which department or thingy you are dealing with. Semantically "descr:" is an easy place to look for a short summary of what the object is about.
A parser can follow the "org:" object for a degree of legal validity, and use "descr:" for an informal, informative textual representation of what the object might be.
Many objects probably already have these descriptions. So if you make it optional and remove the first "descr:" attribute, which is the one that was enforced to be a copy of the org name, then you have what you are asking for.
I am hestitant to remove existing attributes, and would prefer that people remove them when they deem fit (for instance, after they upgraded their software). To me, RIPE NCC finally to stop enforcing the very contents of "descr:" was all that was requested, not a 'clean-up' of sorts. Kind regards, Job
Hi, On 04/08/15 02:49, Job Snijders wrote:
I am hestitant to remove existing attributes, and would prefer that people remove them when they deem fit (for instance, after they upgraded their software).
To me, RIPE NCC finally to stop enforcing the very contents of "descr:" was all that was requested, not a 'clean-up' of sorts.
Kind regards,
Job
+1 I also do not think that the first description line should be removed from all objects because it is a duplicate of the organisation object. It should be made clear that the descr: line (first or any other after) is a free text and is not enforced to anything specific (organisation name, address phone number, or anything else). regards, elvis
Hi all On 04/08/2015 02:04, Elvis Daniel Velea wrote:
Hi,
On 04/08/15 02:49, Job Snijders wrote:
I am hestitant to remove existing attributes, and would prefer that people remove them when they deem fit (for instance, after they upgraded their software).
To me, RIPE NCC finally to stop enforcing the very contents of "descr:" was all that was requested, not a 'clean-up' of sorts.
Kind regards,
Job
+1
I also do not think that the first description line should be removed from all objects because it is a duplicate of the organisation object.
Think carefully about what you are saying here and the long term consequences of these decisions. "duplicate" is the issue here. This database has a massive amount of duplicated data. Lets not leave more duplicated data that is relatively easy to clean up. Even if the RIPE NCC was not asked originally to do a clean up, I would certainly be in favour of asking them to do it now. The whole point of the previous policy was to keep the first description line the same as the org name. I can't remember now if a business rule was added to prevent users from changing it, I have a feeling it was. That means it is still 'the same as' the org name. That makes it easy to identify and remove. Make "descr:" optional and then even if it is the only description it can still be removed. If you leave it, many users will never clean up their data. We know that as a fact of life. Over time the org name in many objects will change with mergers and company name changes. But this will be forgotten about. So we are leaving a completely useless, redundant, mis-leading, initially duplicated piece of data in the database. If you are worried about people needing to upgrade their software to not require to see a mandatory "descr:" attribute, defer the cleanup for a fixed period to allow people to upgrade....as you did with the "changed:" attribute. cheers denis
It should be made clear that the descr: line (first or any other after) is a free text and is not enforced to anything specific (organisation name, address phone number, or anything else).
regards, elvis
Reading *all* INETNUM objects worried me a bit. The first "descr:" attribute of PA Assignments is not mandatorily the legal org name, so I assume the discussion only targets resources directly allocated by the NCC, which contain the legal org name in the first "descr:" line. It is useful to view the org name directly at the top of these objects, for quick reference. However as said the org name can be found with a quick click of the org ID. So to me it's a matter of weighing the importance of keeping a quick org name reference directly in these objects Vs removing duplicate data from the database. Not convinced yet, but I'm leaning towards option b. Always seemed cleaner to me to keep all "descr:" lines free text for consistency, perhaps have a new line "org-name" if legal org name is to be mandatory in these objects. Regards, James -----Original Message----- From: db-wg [mailto:db-wg-bounces@ripe.net] On Behalf Of denis Sent: 04 August 2015 03:26 To: elvis@velea.eu; db-wg@ripe.net Subject: Re: [db-wg] NCC still enforcing descr: content Hi all On 04/08/2015 02:04, Elvis Daniel Velea wrote:
Hi,
On 04/08/15 02:49, Job Snijders wrote:
I am hestitant to remove existing attributes, and would prefer that people remove them when they deem fit (for instance, after they upgraded their software).
To me, RIPE NCC finally to stop enforcing the very contents of "descr:" was all that was requested, not a 'clean-up' of sorts.
Kind regards,
Job
+1
I also do not think that the first description line should be removed from all objects because it is a duplicate of the organisation object.
Think carefully about what you are saying here and the long term consequences of these decisions. "duplicate" is the issue here. This database has a massive amount of duplicated data. Lets not leave more duplicated data that is relatively easy to clean up. Even if the RIPE NCC was not asked originally to do a clean up, I would certainly be in favour of asking them to do it now. The whole point of the previous policy was to keep the first description line the same as the org name. I can't remember now if a business rule was added to prevent users from changing it, I have a feeling it was. That means it is still 'the same as' the org name. That makes it easy to identify and remove. Make "descr:" optional and then even if it is the only description it can still be removed. If you leave it, many users will never clean up their data. We know that as a fact of life. Over time the org name in many objects will change with mergers and company name changes. But this will be forgotten about. So we are leaving a completely useless, redundant, mis-leading, initially duplicated piece of data in the database. If you are worried about people needing to upgrade their software to not require to see a mandatory "descr:" attribute, defer the cleanup for a fixed period to allow people to upgrade....as you did with the "changed:" attribute. cheers denis
It should be made clear that the descr: line (first or any other after) is a free text and is not enforced to anything specific (organisation name, address phone number, or anything else).
regards, elvis
Hi Job and others, The reason we suggested a clean up was because it's an opportunity to get rid of cruft. This is not just good housekeeping, but primarily because maintaining the data comes with certain expectations from the people who use it, which are often the result of habits that go back years. If we quietly stop enforcing the contents of descr: and don't clean up anything, we are concerned this will lead to the confusion that was outlined in the original post with the three alternatives: "names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line." This is why we think option B is the clearest approach, taking all users – both those who enter and use data – into account. We can start with a clean slate and send a clear message to every user. Kind regards Ingrid Wijte Registration Services Assistant Manager RIPE NCC On 04/08/15 01:49, Job Snijders wrote:
On Tue, Aug 04, 2015 at 01:33:05AM +0200, denis wrote:
First of all [...] Thank you for the historical context.
On 03/08/2015 23:50, Job Snijders wrote:
On Mon, Aug 03, 2015 at 11:18:09PM +0200, Sander Steffann wrote:
option B seems like a cleaner long term fix. I agree. I think leaving descr: mandatory will lead to confusion. I disagree, the only confusion so far as been that that attribute's value cannot be a description but in the past had to be the 'proper' company name. This is not quite right. Only the first description line had to be the company name. Other descriptions could have been added and in many cases probably have been. I stand corrected.
Some descr: will refer to an organisation, some will not, some will refer to a different organisation than org:, and for new objects some content for descr: will have to be invented not because there is any useful information but just because the field is mandatory...
If we clean this up I think we should do it properly. To me the "descr:" attribute is an easy to parse component of an IRR object, there is only one "descr:" line, and it is mandatory according to RFC. Not according to the RIPE Database implementation. It is a multiple attribute in all operational objects. When you say "easy to parse" I presume you mean by a human reading the data. Free text is never easy to parse by software. Yes, I meant fit for human consumption (freetext), but easy to find for the parser. "descr:" to me is different then "remarks:", in general I found that "remarks:" is too elaborate while "descr:" is nicely terse.
If I look at organisations that have multiple ASNs the "descr:" attribute can be an informative hint which department or thingy you are dealing with. Semantically "descr:" is an easy place to look for a short summary of what the object is about.
A parser can follow the "org:" object for a degree of legal validity, and use "descr:" for an informal, informative textual representation of what the object might be. Many objects probably already have these descriptions. So if you make it optional and remove the first "descr:" attribute, which is the one that was enforced to be a copy of the org name, then you have what you are asking for. I am hestitant to remove existing attributes, and would prefer that people remove them when they deem fit (for instance, after they upgraded their software).
To me, RIPE NCC finally to stop enforcing the very contents of "descr:" was all that was requested, not a 'clean-up' of sorts.
Kind regards,
Job
Hi Ingrid On 07/08/2015 12:56, Ingrid Wijte wrote:
Hi Job and others,
The reason we suggested a clean up was because it's an opportunity to get rid of cruft. This is not just good housekeeping, but primarily because maintaining the data comes with certain expectations from the people who use it, which are often the result of habits that go back years.
If we quietly stop enforcing the contents of descr: and don't clean up anything, we are concerned this will lead to the confusion that was outlined in the original post with the three alternatives: "names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line."
This is why we think option B is the clearest approach, taking all users – both those who enter and use data – into account. We can start with a clean slate and send a clear message to every user.
I think this is a good approach. It is not good management to leave redundant data in the database especially as it will diverge from the authoritative version of that data. People should also note that there is only a small window of opportunity for the RIPE NCC to do this cleanup effectively. That is at the moment the constraint on the "descr:" attribute is dropped. After that the divergence of the data will start and then it becomes impossible to do a full cleanup. cheers denis
Kind regards
Ingrid Wijte
Registration Services Assistant Manager RIPE NCC
On 04/08/15 01:49, Job Snijders wrote:
On Tue, Aug 04, 2015 at 01:33:05AM +0200, denis wrote:
First of all [...] Thank you for the historical context.
On 03/08/2015 23:50, Job Snijders wrote:
On Mon, Aug 03, 2015 at 11:18:09PM +0200, Sander Steffann wrote:
option B seems like a cleaner long term fix. I agree. I think leaving descr: mandatory will lead to confusion. I disagree, the only confusion so far as been that that attribute's value cannot be a description but in the past had to be the 'proper' company name. This is not quite right. Only the first description line had to be the company name. Other descriptions could have been added and in many cases probably have been. I stand corrected.
Some descr: will refer to an organisation, some will not, some will refer to a different organisation than org:, and for new objects some content for descr: will have to be invented not because there is any useful information but just because the field is mandatory...
If we clean this up I think we should do it properly. To me the "descr:" attribute is an easy to parse component of an IRR object, there is only one "descr:" line, and it is mandatory according to RFC. Not according to the RIPE Database implementation. It is a multiple attribute in all operational objects. When you say "easy to parse" I presume you mean by a human reading the data. Free text is never easy to parse by software. Yes, I meant fit for human consumption (freetext), but easy to find for the parser. "descr:" to me is different then "remarks:", in general I found that "remarks:" is too elaborate while "descr:" is nicely terse.
If I look at organisations that have multiple ASNs the "descr:" attribute can be an informative hint which department or thingy you are dealing with. Semantically "descr:" is an easy place to look for a short summary of what the object is about.
A parser can follow the "org:" object for a degree of legal validity, and use "descr:" for an informal, informative textual representation of what the object might be. Many objects probably already have these descriptions. So if you make it optional and remove the first "descr:" attribute, which is the one that was enforced to be a copy of the org name, then you have what you are asking for. I am hestitant to remove existing attributes, and would prefer that people remove them when they deem fit (for instance, after they upgraded their software).
To me, RIPE NCC finally to stop enforcing the very contents of "descr:" was all that was requested, not a 'clean-up' of sorts.
Kind regards,
Job
On 07/08/2015 15:12, denis wrote:
Hi Ingrid
On 07/08/2015 12:56, Ingrid Wijte wrote:
Hi Job and others,
The reason we suggested a clean up was because it's an opportunity to get rid of cruft. This is not just good housekeeping, but primarily because maintaining the data comes with certain expectations from the people who use it, which are often the result of habits that go back years.
If we quietly stop enforcing the contents of descr: and don't clean up anything, we are concerned this will lead to the confusion that was outlined in the original post with the three alternatives: "names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line."
This is why we think option B is the clearest approach, taking all users – both those who enter and use data – into account. We can start with a clean slate and send a clear message to every user.
I think this is a good approach. It is not good management to leave redundant data in the database especially as it will diverge from the authoritative version of that data. People should also note that there is only a small window of opportunity for the RIPE NCC to do this cleanup effectively. That is at the moment the constraint on the "descr:" attribute is dropped. After that the divergence of the data will start and then it becomes impossible to do a full cleanup.
this is definitely the time to do this, so that the descr: hack can be finally removed from the database. It was only ever suitable as a temporary workaround to handle the lack of org: objects. Nick
On Tue, Jul 28, 2015 at 06:01:29PM +0200, Tim Bruijnzeels wrote:
Option b: Clean up existing cases, "descr:" optional ===================================================== On the other hand if "descr:" could be optional, we would be able to do a bulk change to remove the existing organisation names from the "descr:" of objects, both for end-user resources as well as for allocations. And then leave it to the holders of these objects to modify as they please. This would be the cleanest in the sense that any remaining "descr:" would be fully maintained by the resource holders, and the one place to look for the organisation name is in the referenced organisation object.
Technically this would not be hard for RIPE NCC, but I fully appreciate that a schema change like this has potential big impact on users. That said, if there are many cases where there is no clear case for a "descr:" that is not the organisation name, then this may not be a bad option. Leaving this mandatory would then lead to descr content that is not very useful.
I've read the thread and it seems that the majority is in favor of "option B". I will yield my earlier preference for option A in favor what some in the group have argued to support option B. If you have objections against "option B", please raise them in the next few days, with arguments. I aim to discuss what has been said with the other chairs next week (or the week after if the discussion continues). Summary option B: - remove all mandatory populated 'descr:' attributes (the first descr: of an object) - change 'descr:' to be an optional attribute This change would essentially make 'descr:' and 'remarks:' the same. Kind regards, Job
HI Job On 12/08/2015 16:13, Job Snijders wrote:
Summary option B: - remove all mandatory populated 'descr:' attributes (the first descr: of an object) - change 'descr:' to be an optional attribute
This change would essentially make 'descr:' and 'remarks:' the same.
I think some clarification is also needed on the future use of the "descr:" attribute. When you say it is the same as "remarks:" you can also argue that "address:" is the same as "remarks:". They are all attributes containing free text values. The slight difference is that both "address:" and "descr:" are only allowed in certain object types. Most people know what is expected to be in an "address:" attribute and would not use it for additional comments, even though you could. Maybe some guide lines are now needed about what is expected in a "descr:" attribute if it is optionally included. Any guidelines agreed could be included in documentation and help output, for example with a '-v' query. cheers denis
Kind regards,
Job
On Wed, Aug 12, 2015 at 08:26:09PM +0200, denis wrote:
On 12/08/2015 16:13, Job Snijders wrote:
Summary option B: - remove all mandatory populated 'descr:' attributes (the first descr: of an object) - change 'descr:' to be an optional attribute
This change would essentially make 'descr:' and 'remarks:' the same.
I think some clarification is also needed on the future use of the "descr:" attribute. When you say it is the same as "remarks:" you can also argue that "address:" is the same as "remarks:". They are all attributes containing free text values.
yeah, this was just my observation.
The slight difference is that both "address:" and "descr:" are only allowed in certain object types. Most people know what is expected to be in an "address:" attribute and would not use it for additional comments, even though you could. Maybe some guide lines are now needed about what is expected in a "descr:" attribute if it is optionally included. Any guidelines agreed could be included in documentation and help output, for example with a '-v' query.
What do you think should be in "descr:"? Do you have suggestions for new guidelines for descr:? Kind regards, Job
Hi Job Another point just crossed my mind. The "descr:" attribute is mandatory in the following object types: inetnum inet6num aut-num route route6 various set objects Was the first "descr:" attribute in all these object types constrained to represent the organisation? If not which ones was it constrained in, which ones are you going to make it optional in and which are going to be 'cleaned up'? As for what does a description mean in any/each of these object types I will leave that to the more operationally minded people in the community. But I think it would be good to clarify what it does mean in each object type as this has never been defined before. cheers denis On 12/08/2015 20:31, Job Snijders wrote:
On Wed, Aug 12, 2015 at 08:26:09PM +0200, denis wrote:
On 12/08/2015 16:13, Job Snijders wrote:
Summary option B: - remove all mandatory populated 'descr:' attributes (the first descr: of an object) - change 'descr:' to be an optional attribute
This change would essentially make 'descr:' and 'remarks:' the same.
I think some clarification is also needed on the future use of the "descr:" attribute. When you say it is the same as "remarks:" you can also argue that "address:" is the same as "remarks:". They are all attributes containing free text values.
yeah, this was just my observation.
The slight difference is that both "address:" and "descr:" are only allowed in certain object types. Most people know what is expected to be in an "address:" attribute and would not use it for additional comments, even though you could. Maybe some guide lines are now needed about what is expected in a "descr:" attribute if it is optionally included. Any guidelines agreed could be included in documentation and help output, for example with a '-v' query.
What do you think should be in "descr:"? Do you have suggestions for new guidelines for descr:?
Kind regards,
Job
On Wed, Aug 12, 2015 at 08:43:50PM +0200, denis wrote:
Another point just crossed my mind. The "descr:" attribute is mandatory in the following object types: inetnum inet6num aut-num route route6 various set objects
Was the first "descr:" attribute in all these object types constrained to represent the organisation?
From the above list only in inetnum, inet6num, aut-num. In route and route6 it can be whatever you want but the presence of the 'descr:' attribute is mandatory.
If not which ones was it constrained in, which ones are you going to make it optional in and which are going to be 'cleaned up'?
As I understood 'option B' the clean-up would happen for "descr:" lines which were/are enforced, if they aren't enforced then we can assume the data is what the End User wants it to be, and there would be no need to touch such lines.
As for what does a description mean in any/each of these object types I will leave that to the more operationally minded people in the community. But I think it would be good to clarify what it does mean in each object type as this has never been defined before.
For me as operator, I think I'd like "descr:" to be a one-line description what the object is about. If an organisation has many aut-nums, it would be beneficial if there is one line which describes the differences between all those aut-nums by providing a one-line summary. Because of "org:" I can programmatically follow which organisation it belongs to, but some more meta-data might be useful. Thoughts? Kind regards, Job
Hi Job On 12/08/2015 20:55, Job Snijders wrote:
On Wed, Aug 12, 2015 at 08:43:50PM +0200, denis wrote:
Another point just crossed my mind. The "descr:" attribute is mandatory in the following object types: inetnum inet6num aut-num route route6 various set objects
Was the first "descr:" attribute in all these object types constrained to represent the organisation?
From the above list only in inetnum, inet6num, aut-num. In route and route6 it can be whatever you want but the presence of the 'descr:' attribute is mandatory.
If not which ones was it constrained in, which ones are you going to make it optional in and which are going to be 'cleaned up'?
As I understood 'option B' the clean-up would happen for "descr:" lines which were/are enforced, if they aren't enforced then we can assume the data is what the End User wants it to be, and there would be no need to touch such lines.
So are you OK with a final situation where "descr:" is optional in some objects and still mandatory in others?
As for what does a description mean in any/each of these object types I will leave that to the more operationally minded people in the community. But I think it would be good to clarify what it does mean in each object type as this has never been defined before.
For me as operator, I think I'd like "descr:" to be a one-line description what the object is about. If an organisation has many aut-nums, it would be beneficial if there is one line which describes the differences between all those aut-nums by providing a one-line summary. Because of "org:" I can programmatically follow which organisation it belongs to, but some more meta-data might be useful.
As a neutral observer from operational point of view, that makes sense to me. But does that mean you would like to make the attribute 'single' instead of 'multiple' as it is now? If you make it single what would you do with objects that already have multiple lines (besides the org name)? You could convert any existing additional lines into "remarks:". cheers denis
Thoughts?
Kind regards,
Job
On Wed, Aug 12, 2015 at 09:11:14PM +0200, denis wrote:
On 12/08/2015 20:55, Job Snijders wrote:
On Wed, Aug 12, 2015 at 08:43:50PM +0200, denis wrote:
Another point just crossed my mind. The "descr:" attribute is mandatory in the following object types: inetnum inet6num aut-num route route6 various set objects
Was the first "descr:" attribute in all these object types constrained to represent the organisation?
From the above list only in inetnum, inet6num, aut-num. In route and route6 it can be whatever you want but the presence of the 'descr:' attribute is mandatory.
If not which ones was it constrained in, which ones are you going to make it optional in and which are going to be 'cleaned up'?
As I understood 'option B' the clean-up would happen for "descr:" lines which were/are enforced, if they aren't enforced then we can assume the data is what the End User wants it to be, and there would be no need to touch such lines.
So are you OK with a final situation where "descr:" is optional in some objects and still mandatory in others?
If we make 'descr:' optional, i'd prefer it to be optional across the entire board.
As for what does a description mean in any/each of these object types I will leave that to the more operationally minded people in the community. But I think it would be good to clarify what it does mean in each object type as this has never been defined before.
For me as operator, I think I'd like "descr:" to be a one-line description what the object is about. If an organisation has many aut-nums, it would be beneficial if there is one line which describes the differences between all those aut-nums by providing a one-line summary. Because of "org:" I can programmatically follow which organisation it belongs to, but some more meta-data might be useful.
As a neutral observer from operational point of view, that makes sense to me. But does that mean you would like to make the attribute 'single' instead of 'multiple' as it is now? If you make it single what would you do with objects that already have multiple lines (besides the org name)? You could convert any existing additional lines into "remarks:".
I have no particular preference whether single or multiple is better. If anything, it would be a matter of clearly documentating. Given that "remarks:" already is multiple, it might make sense to declare "descr:" as 'single' and thus offer a clear differentiator between the two. "descr:" - one-line optional summary what the object is about "remarks:" - the story of your life Kind regards, Job
On 12.08.2015 21:19, Job Snijders wrote:
So are you OK with a final situation where "descr:" is optional in some objects and still mandatory in others?
If we make 'descr:' optional, i'd prefer it to be optional across the entire board.
+1
For me as operator, I think I'd like "descr:" to be a one-line description what the object is about. If an organisation has many aut-nums, it would be beneficial if there is one line which describes the differences between all those aut-nums by providing a one-line summary. Because of "org:" I can programmatically follow which organisation it belongs to, but some more meta-data might be useful.
Yes, that's why I like the "descr:", too.
As a neutral observer from operational point of view, that makes sense to me. But does that mean you would like to make the attribute 'single' instead of 'multiple' as it is now? If you make it single what would you do with objects that already have multiple lines (besides the org name)? You could convert any existing additional lines into "remarks:".
I have no particular preference whether single or multiple is better. If anything, it would be a matter of clearly documentating.
Given that "remarks:" already is multiple, it might make sense to declare "descr:" as 'single' and thus offer a clear differentiator between the two.
"descr:" - one-line optional summary what the object is about "remarks:" - the story of your life
That would work for me. Cheers, Tim
participants (10)
-
denis -
Elvis Daniel Velea -
Ingrid Wijte -
Jan Saner -
Job Snijders -
Kennedy, James -
Nick Hilliard -
Sander Steffann -
Tim Bruijnzeels -
Tim Kleefass