"status:" attribute values in the RIPE database
Dear colleagues, In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that resource "status:" attribute values may not always be all UPPERCASE. This is because the RIPE database is case-insensitive and case preserving in general, meaning a "status:" attribute value is the same regardless of the case. However, this may make parsing this value more difficult as the case should be ignored. Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency? Regards Ed Shryane RIPE NCC
Hi, On Mon, Jun 07, 2021 at 11:09:31AM +0200, Edward Shryane via db-wg wrote:
Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency?
As a DB user, I would find this useful. Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear Ed,
Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency?
As a DB user, I would find this useful.
I agree with Gert. Although it is quite easy to convert the output to lowercase or uppercase as one wishes, it is also easy to forget about it, an be surprised about the result. Best regards, Janos
Gert Doering
On Mon, 7 Jun 2021 at 11:41, Janos Zsako via db-wg <db-wg@ripe.net> wrote:
I agree with Gert. Although it is quite easy to convert the output to lowercase or uppercase as one wishes, it is also easy to forget about it and be surprised about the result.
Agreed, go for the path of least surprises ⇒ enforce case consistency. -- Chriztoffer
Hi, On Mon, 2021-06-07 at 11:55 +0200, Chriztoffer Hansen via db-wg wrote:
On Mon, 7 Jun 2021 at 11:41, Janos Zsako via db-wg <db-wg@ripe.net> wrote:
I agree with Gert. Although it is quite easy to convert the output to lowercase or uppercase as one wishes, it is also easy to forget about it and be surprised about the result.
Agreed, go for the path of least surprises ⇒ enforce case consistency.
+1 to that. I know I would forget that myself 🙂 Sander
Agreed, go for the path of least surprises ⇒ enforce case consistency. +1 to that. I know I would forget that myself 🙂
except the change is not POLA at all, is it? randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
On Mon, Jun 07, 2021 at 11:09:31AM +0200, Edward Shryane via db-wg wrote:
Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency?
Sounds ok for me. Best, Piotr -- Piotr Strzyżewski
Ed & all - makes sense to me, too. However: Instead of forcing this on the creator/updater of an object - how about the NCC to be as liberal as possible (John Postel's law, the robustness principle) and to accept any case combination, e.g. "aSSigNED pi", but very conservatively keep the attribute sored in the DB in uppercase only? ATB, -C. On 07.06.2021 11:09, Edward Shryane via db-wg wrote:
Dear colleagues,
In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that resource "status:" attribute values may not always be all UPPERCASE.
This is because the RIPE database is case-insensitive and case preserving in general, meaning a "status:" attribute value is the same regardless of the case.
However, this may make parsing this value more difficult as the case should be ignored.
Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency?
Regards Ed Shryane RIPE NCC
In message <A71ACCE1-3BFB-453A-A9EF-2D8D8FD686C8@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:
... However, this may make parsing this value more difficult as the case should be ignored.
Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency?
Yes, please. That's a STRONG yes from me. In fact, it would be most helpful if this could be done for ALL field values that are in fact case insensitive, in particular ALL symbolic handles, as well as all country: attributes, etc. Of course, company names and street addresses are best left as they are, as well as all email addresses. (The last time I checked, there was nothing within any of the relevant RFCs that explicity stipulated that the user-id portion of an email address either SHALL or MUST or SHOULD be treated as case insensitive. Thus, some of them may in fact be case sensitive, and thus they should all remain exactly as the parties who put them into the data base wrote them.) Regards, rfg P.S. It also complicates parsing... rather needlessly in my view... to have some field values optionally followed by commentary text beginning with #. I can't remember now if this was only a problem I saw with respect to the APNIC data base, or if this sickness has also infected some RIPE WHOIS records, but if RIPE allows it, I wish you wouldn't. One other small parsing annoyance: Continuation lines. I only saw a single instance of this and only in the APNIC WHOIS data base, but it was quite annoying. There was/is a continued line / field value that looked like this: inetnum: A1.B1.C1.D1 - A2.B2.C2.D2 My parser wasn't expecting THAT!
On Mon, Jun 7, 2021 at 4:48 PM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote: [...]
P.S. It also complicates parsing... rather needlessly in my view... to have some field values optionally followed by commentary text beginning with #. I can't remember now if this was only a problem I saw with respect to the APNIC data base, or if this sickness has also infected some RIPE WHOIS records, but if RIPE allows it, I wish you wouldn't.
One other small parsing annoyance: Continuation lines. I only saw a single instance of this and only in the APNIC WHOIS data base, but it was quite annoying. There was/is a continued line / field value that looked like this:
inetnum: A1.B1.C1.D1 - A2.B2.C2.D2
My parser wasn't expecting THAT!
These and the case insensitivity are all features defined in RFC 2280 and carried over into its successors. Databases that implement RPSL are likely to have implemented these features as they are part of the specification. To be fair to the authors, there were fewer than 150m Internet users in the world when that original specification was published. Things probably looked quite different! Regards, Leo
On Mon, Jun 07, 2021 at 04:48:38PM -0700, Ronald F. Guilmette via db-wg wrote:
inetnum: A1.B1.C1.D1 - A2.B2.C2.D2
My parser wasn't expecting THAT!
That says a lot about the parser, as this is well described in documentation: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... ;-) Best, Piotr -- Piotr Strzyżewski
In message <YL89iirxN8Q9SlXS@hydra.ck.polsl.pl>, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
On Mon, Jun 07, 2021 at 04:48:38PM -0700, Ronald F. Guilmette via db-wg wrote:
inetnum: A1.B1.C1.D1 - A2.B2.C2.D2
My parser wasn't expecting THAT!
That says a lot about the parser, as this is well described in documentation:
Although it may have escaped your attention, as a general matter, reality frequently diverges from documentation. In any case, it is easily possible to parse WHOIS records sufficiently well to do a multitude of useful things without consulting any documentation of the format. It can be done just by eyeballing what is fundamentally a rather simple syntax. Furthermore, as I noted, there are literally hundreds of thousands of objects in the APNIC data base. Of these only a single one had an inetnum: field that was splattered, needlessly, and for no apparently good reason, across multiple lines. (I hope to soon find out whether such pointless oddities are present also in the RIPE data base.) Regards, rfg
Hi Ronald It says in the documentation that you cannot split the primary key attribute value over multiple lines. To make sure that is still the case, I just tried to create this object in the test database: INETNUM: 10.0.0.0 - 10.0.0.255 NETNAME: fred descr: whatever COUNTRY: NL ADMIN-C: dw-test TECH-C: dw-test abuse-c: unread@ripe.net STATUS: Assigned Pa MNT-BY: AARDVARK-MNT SOURCE: TEST this is the response I got back: Create FAILED: [inetnum] 10.0.0.0 - 10.0.0.255 inetnum: 10.0.0.0 - 10.0.0.255 ***Info: Continuation lines are not allowed here and have been removed netname: fred descr: whatever country: NL admin-c: dw-test tech-c: dw-test abuse-c: unread@ripe.net ***Error: Syntax error in unread@ripe.net status: ASSIGNED PA ***Info: Value Assigned Pa converted to ASSIGNED PA mnt-by: AARDVARK-MNT source: TEST The important bit is that first info message: ***Info: Continuation lines are not allowed here and have been removed Exactly as it says in the documentation, the pkey split lines have been merged back into a single line separated by single spaces and without causing an error. cheers denis co-chair DB-WG On Tue, 8 Jun 2021 at 23:45, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <YL89iirxN8Q9SlXS@hydra.ck.polsl.pl>, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
On Mon, Jun 07, 2021 at 04:48:38PM -0700, Ronald F. Guilmette via db-wg wrote:
inetnum: A1.B1.C1.D1 - A2.B2.C2.D2
My parser wasn't expecting THAT!
That says a lot about the parser, as this is well described in documentation:
Although it may have escaped your attention, as a general matter, reality frequently diverges from documentation.
In any case, it is easily possible to parse WHOIS records sufficiently well to do a multitude of useful things without consulting any documentation of the format. It can be done just by eyeballing what is fundamentally a rather simple syntax.
Furthermore, as I noted, there are literally hundreds of thousands of objects in the APNIC data base. Of these only a single one had an inetnum: field that was splattered, needlessly, and for no apparently good reason, across multiple lines.
(I hope to soon find out whether such pointless oddities are present also in the RIPE data base.)
Regards, rfg
In message <CAKvLzuFiy3gn7Q3JSHXbaMO58qHOUkbfX-SPZuXx_7b8qxrDOQ@mail.gmail.com> denis wrote:
It says in the documentation that you cannot split the primary key attribute value over multiple lines. To make sure that is still the case, I just tried to create this object in the test database:
Excellent. I only wish that the folks @ APNIC were as helpful. I tried suggesting to them that their record covering 118.102.134.160/28 was, you know, sub-optimal, but as they often do, they said this isn't their problem and recommended that I go and talk to someone else about the issue, you know, if I really cared about it. If was faster just to program around the problem. Regards, rfg
It says in the documentation that you cannot split the primary key attribute value over multiple lines.
it's a shame that the NCC does not have a webinar on db use. oh, wait. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
Ronald F. Guilmette via db-wg wrote on 08/06/2021 00:48:
The last time I checked, there was nothing within any of the relevant RFCs that explicity stipulated that the user-id portion of an email address either SHALL or MUST or SHOULD be treated as case insensitive
the <local> part of an rfc821/rfc2821 email address has always been case-sensitive. Otherwise, almost all if not all tokens in ripe181++ syntax are case insensitive, and always needed either case translation or case-insensitive comparison to process correctly. Nick
Colleagues The chairs recognise a consensus to force "status:" values to uppercase on updates and for the RIPE NCC to perform a one time update across the database to convert existing "status:" values to uppercase where necessary. We ask the RIPE NCC to go ahead with this process and inform the community of their implementation plans. regards William & denis co-chairs DB-WG On Mon, 7 Jun 2021 at 11:09, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that resource "status:" attribute values may not always be all UPPERCASE.
This is because the RIPE database is case-insensitive and case preserving in general, meaning a "status:" attribute value is the same regardless of the case.
However, this may make parsing this value more difficult as the case should be ignored.
Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency?
Regards Ed Shryane RIPE NCC
Dear Colleagues, Thanks to the co-chairs for declaring a consensus, the DB team will start working on the implementation. The implementation plan consists of two parts: (1) Update Whois business rule validation We will add a business rule to require the "status:" attribute value in inetnum, inet6num and aut-num objects to be completely in UPPERCASE. This business rule will apply when creating or updating these object types. If the "status:" value is not completely in uppercase, the software will automatically convert the value to uppercase and add a warning in the update response, immediately following the "status:" attribute: "***Warning: The status value was converted to uppercase". The update will not fail if this happens. We plan to deploy this change in the next Whois release (provisionally, version 1.102). (2) Cleanup existing non-uppercase "status:" values in the RIPE database Following the Whois release, we will run a cleanup script to convert all existing non-uppercase "status:" values to uppercase. We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a non-uppercase "status:" value. As only the case of the "status:" value is changed, the objects remain syntactically the same. We will not send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history). All changes will be visible in NRTM as the objects are updated. The change can be considered a NOOP. All changes will be visible in that night's database dump and split files. We expect the cleanup script to take approximately an hour to complete all updates. Cleanup script updates will be applied cooperatively between normal updates, we do not expect any interruption to Whois updates. Please let me know if you have any questions. Regards Ed Shryane RIPE NCC
On 27 Jul 2021, at 15:59, denis walker <ripedenis@gmail.com> wrote:
Colleagues
The chairs recognise a consensus to force "status:" values to uppercase on updates and for the RIPE NCC to perform a one time update across the database to convert existing "status:" values to uppercase where necessary.
We ask the RIPE NCC to go ahead with this process and inform the community of their implementation plans.
regards William & denis co-chairs DB-WG
On Mon, 7 Jun 2021 at 11:09, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that resource "status:" attribute values may not always be all UPPERCASE.
This is because the RIPE database is case-insensitive and case preserving in general, meaning a "status:" attribute value is the same regardless of the case.
However, this may make parsing this value more difficult as the case should be ignored.
Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency?
Regards Ed Shryane RIPE NCC
Dear DB-WG, Le mer. 28 juil. 2021 à 4:15 PM, Edward Shryane via db-wg <db-wg@ripe.net> a écrit :
Dear Colleagues,
Hi Edward, Thanks for your notification, brother.
Thanks to the co-chairs for declaring a consensus, the DB team will start working on the implementation.
The implementation plan consists of two parts:
[...] As only the case of the "status:" value is changed, the objects remain syntactically the same. We will not send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history).
...ok, cool! Question, please: is it a bad idea to add a comment as in "remarks:" attribute? Shalom, --sb.
All changes will be visible in NRTM as the objects are updated. The change can be considered a NOOP.
All changes will be visible in that night's database dump and split files.
[...]
Please let me know if you have any questions.
Regards Ed Shryane RIPE NCC
[...]
Hi Taking my co-chair hat off, my personal view is, yes it is a bad idea to add a remark. This has been done many times in the past where objects have been modified as part of an agreed update. Some of these remarks have never been removed. They have been there for over 10 years. Objects then get bloated with multiple remarks about several updates. It just becomes unnecessary clutter. If the update has been well announced on the mailing list, maintainers have been notified of the modification and it shows in the object history then I don't think a remark is needed as well. cheers denis On Wed, 4 Aug 2021 at 16:06, Sylvain Baya <abscoco@gmail.com> wrote:
Dear DB-WG,
Le mer. 28 juil. 2021 à 4:15 PM, Edward Shryane via db-wg <db-wg@ripe.net> a écrit :
Dear Colleagues,
Hi Edward, Thanks for your notification, brother.
Thanks to the co-chairs for declaring a consensus, the DB team will start working on the implementation.
The implementation plan consists of two parts:
[...] As only the case of the "status:" value is changed, the objects remain syntactically the same. We will not send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history).
...ok, cool! Question, please: is it a bad idea to add a comment as in "remarks:" attribute?
Shalom, --sb.
All changes will be visible in NRTM as the objects are updated. The change can be considered a NOOP.
All changes will be visible in that night's database dump and split files.
[...]
Please let me know if you have any questions.
Regards Ed Shryane RIPE NCC
[...]
Dear DB-WG, Please see my comment below, inline... Le mercredi 4 août 2021, denis walker <ripedenis@gmail.com> a écrit :
Hi
Taking my co-chair hat off, my personal view is, yes it is a bad idea to add a remark. This has been done many times in the past where objects have been modified as part of an agreed update. Some of these remarks have never been removed. They have been there for over 10 years. Objects then get bloated with multiple remarks about several updates. It just becomes unnecessary clutter. If the update has been well announced on the mailing list, maintainers have been notified of the modification and it shows in the object history then I don't think a remark is needed as well.
Thanks for your explanation, dear Denis. ...now, i understand that the version history is sufficient to both 'keep' the change and to get the interested users, of the whois service, informed about it existence. Shalom, --sb.
cheers denis
On Wed, 4 Aug 2021 at 16:06, Sylvain Baya <abscoco@gmail.com> wrote:
Dear DB-WG,
Le mer. 28 juil. 2021 à 4:15 PM, Edward Shryane via db-wg <
db-wg@ripe.net> a écrit :
Dear Colleagues,
Hi Edward, Thanks for your notification, brother.
Thanks to the co-chairs for declaring a consensus, the DB team will
start working on the implementation.
The implementation plan consists of two parts:
[...] As only the case of the "status:" value is changed, the objects remain
syntactically the same. We will not send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history).
...ok, cool! Question, please: is it a bad idea to add a comment as in "remarks:" attribute?
Shalom, --sb.
All changes will be visible in NRTM as the objects are updated. The
change can be considered a NOOP.
All changes will be visible in that night's database dump and split
files.
[...]
Please let me know if you have any questions.
Regards Ed Shryane RIPE NCC
[...]
-- -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #LASAINTEBIBLE|#Romains15:33«Que LE #DIEU de #Paix soit avec vous tous! #Amen!» #MaPrière est que tu naisses de nouveau. #Chrétiennement «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)
Dear Colleagues, After starting work on the implementation, we discovered that "status:" values are *already* automatically converted to uppercase on update. This was implemented in Whois release 1.73.1 and deployed on 27th May 2014, but existing non-uppercase values were not cleaned up at the time. I propose simplifying the implementation plan as follows: (1) Update Whois business rule validation (already implemented) When a non-uppercase "status:" value is converted to uppercase, a global informational message is added to the response: ***Info: Value %s converted to %s (2) Cleanup existing non-uppercase "status:" values in the RIPE database On next *Monday 30th August*, we will run a cleanup script to convert all existing non-uppercase "status:" values to uppercase. We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a non-uppercase "status:" value. As only the case of the "status:" value is changed, the objects remain syntactically the same. We will *not* send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history). All changes will be visible in NRTM as the objects are updated. The change can be considered a NOOP. All changes will be visible in that night's database dump and split files. We expect the cleanup script to take approximately an hour to complete all updates. Cleanup script updates will be applied cooperatively between normal updates, we do not expect any interruption to Whois updates. Regards Ed Shryane RIPE NCC
On 28 Jul 2021, at 17:15, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear Colleagues,
Thanks to the co-chairs for declaring a consensus, the DB team will start working on the implementation.
The implementation plan consists of two parts:
(1) Update Whois business rule validation
We will add a business rule to require the "status:" attribute value in inetnum, inet6num and aut-num objects to be completely in UPPERCASE.
This business rule will apply when creating or updating these object types.
If the "status:" value is not completely in uppercase, the software will automatically convert the value to uppercase and add a warning in the update response, immediately following the "status:" attribute: "***Warning: The status value was converted to uppercase". The update will not fail if this happens.
We plan to deploy this change in the next Whois release (provisionally, version 1.102).
(2) Cleanup existing non-uppercase "status:" values in the RIPE database
Following the Whois release, we will run a cleanup script to convert all existing non-uppercase "status:" values to uppercase.
We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a non-uppercase "status:" value.
As only the case of the "status:" value is changed, the objects remain syntactically the same. We will not send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history).
All changes will be visible in NRTM as the objects are updated. The change can be considered a NOOP.
All changes will be visible in that night's database dump and split files.
We expect the cleanup script to take approximately an hour to complete all updates.
Cleanup script updates will be applied cooperatively between normal updates, we do not expect any interruption to Whois updates.
Please let me know if you have any questions.
Regards Ed Shryane RIPE NCC
On 27 Jul 2021, at 15:59, denis walker <ripedenis@gmail.com> wrote:
Colleagues
The chairs recognise a consensus to force "status:" values to uppercase on updates and for the RIPE NCC to perform a one time update across the database to convert existing "status:" values to uppercase where necessary.
We ask the RIPE NCC to go ahead with this process and inform the community of their implementation plans.
regards William & denis co-chairs DB-WG
On Mon, 7 Jun 2021 at 11:09, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that resource "status:" attribute values may not always be all UPPERCASE.
This is because the RIPE database is case-insensitive and case preserving in general, meaning a "status:" attribute value is the same regardless of the case.
However, this may make parsing this value more difficult as the case should be ignored.
Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency?
Regards Ed Shryane RIPE NCC
Dear Colleagues, We have now run the cleanup job to uppercase all "status:" attribute values, and updated 23,890 objects in total. Regards Ed Shryane RIPE NCC
On 24 Aug 2021, at 13:39, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear Colleagues,
After starting work on the implementation, we discovered that "status:" values are *already* automatically converted to uppercase on update. This was implemented in Whois release 1.73.1 and deployed on 27th May 2014, but existing non-uppercase values were not cleaned up at the time.
I propose simplifying the implementation plan as follows:
(1) Update Whois business rule validation (already implemented)
When a non-uppercase "status:" value is converted to uppercase, a global informational message is added to the response:
***Info: Value %s converted to %s
(2) Cleanup existing non-uppercase "status:" values in the RIPE database
On next *Monday 30th August*, we will run a cleanup script to convert all existing non-uppercase "status:" values to uppercase.
We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a non-uppercase "status:" value.
As only the case of the "status:" value is changed, the objects remain syntactically the same. We will *not* send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history).
All changes will be visible in NRTM as the objects are updated. The change can be considered a NOOP.
All changes will be visible in that night's database dump and split files.
We expect the cleanup script to take approximately an hour to complete all updates.
Cleanup script updates will be applied cooperatively between normal updates, we do not expect any interruption to Whois updates.
Regards Ed Shryane RIPE NCC
On 28 Jul 2021, at 17:15, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear Colleagues,
Thanks to the co-chairs for declaring a consensus, the DB team will start working on the implementation.
The implementation plan consists of two parts:
(1) Update Whois business rule validation
We will add a business rule to require the "status:" attribute value in inetnum, inet6num and aut-num objects to be completely in UPPERCASE.
This business rule will apply when creating or updating these object types.
If the "status:" value is not completely in uppercase, the software will automatically convert the value to uppercase and add a warning in the update response, immediately following the "status:" attribute: "***Warning: The status value was converted to uppercase". The update will not fail if this happens.
We plan to deploy this change in the next Whois release (provisionally, version 1.102).
(2) Cleanup existing non-uppercase "status:" values in the RIPE database
Following the Whois release, we will run a cleanup script to convert all existing non-uppercase "status:" values to uppercase.
We found approximately 21,492 out of 4,217,303 inetnum objects; 2,577 out of 655,856 inet6num objects; 0 out of 37,056 aut-num objects, with a non-uppercase "status:" value.
As only the case of the "status:" value is changed, the objects remain syntactically the same. We will not send notification emails to maintainers for the change, apart from notifying the db-wg. The "last-modified:" value will not change, but a new object version will be created (so the change will be visible in the version history).
All changes will be visible in NRTM as the objects are updated. The change can be considered a NOOP.
All changes will be visible in that night's database dump and split files.
We expect the cleanup script to take approximately an hour to complete all updates.
Cleanup script updates will be applied cooperatively between normal updates, we do not expect any interruption to Whois updates.
Please let me know if you have any questions.
Regards Ed Shryane RIPE NCC
On 27 Jul 2021, at 15:59, denis walker <ripedenis@gmail.com> wrote:
Colleagues
The chairs recognise a consensus to force "status:" values to uppercase on updates and for the RIPE NCC to perform a one time update across the database to convert existing "status:" values to uppercase where necessary.
We ask the RIPE NCC to go ahead with this process and inform the community of their implementation plans.
regards William & denis co-chairs DB-WG
On Mon, 7 Jun 2021 at 11:09, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that resource "status:" attribute values may not always be all UPPERCASE.
This is because the RIPE database is case-insensitive and case preserving in general, meaning a "status:" attribute value is the same regardless of the case.
However, this may make parsing this value more difficult as the case should be ignored.
Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency?
Regards Ed Shryane RIPE NCC
participants (13)
-
Carsten Schiefner -
Chriztoffer Hansen -
denis walker -
Edward Shryane -
Gert Doering -
Janos Zsako -
Leo Vegoda -
Nick Hilliard -
Piotr Strzyzewski -
Randy Bush -
Ronald F. Guilmette -
Sander Steffann -
Sylvain Baya