Validation on "org-name:" syntax (double spaces and newlines)
Dear Working Group, Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following: 1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input I am leaning towards option 2, but I would value your input. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC
I would prefer option 1, because it can make things easier for guys not familiar with unix system. On Sun, Nov 12, 2017 at 07:35 Tim Bruijnzeels via db-wg <db-wg@ripe.net> wrote:
Dear Working Group,
Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects.
Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following:
1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input
I am leaning towards option 2, but I would value your input.
Kind regards,
Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC
-- -- Kind regards. Lu
Dear Lu,
On 12 Nov 2017, at 15:03, Lu Heng <h.lu@anytimechinese.com> wrote:
I would prefer option 1, because it can make things easier for guys not familiar with unix system.
I am not sure that I follow. But I realise I was incomplete in my statement. If people use the web interface to update their organisation object then we will make sure that we reject incorrect input and give a clear error message. So, option 1 vs 2 is applicable only, when people submit updates through other means, or through automated tools, e.g. syncupdates or mailupdates. I don’t see how avoiding multi-whitespace (or a multi-line) values is any harder on windows in these cases. Option 2 is the least surprising - no magic changes. Option 1 could be good if unattended scripts would otherwise break and stay broken, but given that we are talking around 0.1% of objects I doubt that this is a real world issue. Tim
On Sun, Nov 12, 2017 at 07:35 Tim Bruijnzeels via db-wg <db-wg@ripe.net> wrote: Dear Working Group,
Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects.
Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following:
1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input
I am leaning towards option 2, but I would value your input.
Kind regards,
Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC -- -- Kind regards. Lu
Tim Bruijnzeels via db-wg wrote:
1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input
I am leaning towards option 2, but I would value your input.
strong preference to fix; mild preference towards #2. Nick
I prefer #2 Am 12.11.17 um 07:35 schrieb Tim Bruijnzeels via db-wg:
Dear Working Group,
Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects.
Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following:
1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input
I am leaning towards option 2, but I would value your input.
Kind regards,
Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC
-- Mit freundlichem Gruß Artfiles New Media GmbH Andreas Worbs Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support@artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478
Hi Colleagues A few comments expressed a slight preference for option 2 below, rejecting updates with multiple whitespace. So with my devil's advocate hat on let me make a comment. Putting multiple whitespaces in any text string in the database input has no meaning or benefit to anyone (except in "remarks:" for formatted information blocks). So when it occurs it is an obvious typo or misunderstanding of how the database works. The fix for it, compressing the multiple whitespaces into a single space, is clearly defined and I can't think of any situation where applying that fix would corrupt the data. If the database software applies that fix automatically in any situation (except in "remarks:") it makes the database slightly more user friendly. So I don't see the need to reject any update for this mistake, and make users do more work, when it can be so easily fixed. I don't even see the need for any informational message back to the users about applying this fix to their data. Also I would like to see this fix applied to input from Webupdates as well. It is such an obvious and easy fix, why make it an issue. We do have a precedence for this. If you include multiple spaces in an INETNUM range either side of the '-' they are fixed by the software and reduced to a single space. No info message is included in the ack message. cheersdenisco-chair DB WG From: Tim Bruijnzeels via db-wg <db-wg@ripe.net> To: Database WG <db-wg@ripe.net> Sent: Sunday, 12 November 2017, 7:35 Subject: [db-wg] Validation on "org-name:" syntax (double spaces and newlines) Dear Working Group, Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following: 1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input I am leaning towards option 2, but I would value your input. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC
On 22 November 2017 at 22:19, denis walker via db-wg <db-wg@ripe.net> wrote:
If the database software applies that fix automatically in any situation (except in "remarks:") it makes the database slightly more user friendly. So I don't see the need to reject any update for this mistake, and make users do more work, when it can be so easily fixed. I don't even see the need for any informational message back to the users about applying this fix to their data. Also I would like to see this fix applied to input from Webupdates as well. It is such an obvious and easy fix, why make it an issue.
We do have a precedence for this. If you include multiple spaces in an INETNUM range either side of the '-' they are fixed by the software and reduced to a single space. No info message is included in the ack message.
Pls approve (& implement). Thx. (& for all the work you do as chairs) /christoffer
participants (6)
-
Andreas Worbs -
Christoffer Dam Hansen -
denis walker -
Lu Heng -
Nick Hilliard -
Tim Bruijnzeels