whois output and the "changed" line.
Dear Colleagues, Recently, the output of our whois server was modified; the "changed" information is not shown by default. To see it, the new "-c" flag must be used. This requires using the new RIPE whois client. The "changed" information was removed from the default output of whois after a discussion on the mailing list of the RIPE Database Working Group. This discussion was about the funtionality of the "changed" line. A long-term replacement for it (i.e. timestamping of updates) is planned. However, there is the possibility that the existing "changed" lines can be accidently deleted from objects. When users want to update an object, they do a whois look-up and re-direct the output into a temporary file. Then, they edit the file and send it to <auto-dbm@ripe.net>. Thus, before the output of the whois server was modified, the update contained all the previous changed fields. Now, unless the user does "whois -c", the "changed" attributes are not shown. But when users want to update an object, they re-direct a whois look-up into a file, edit it and then send it to the database. However, this time, the "changed" lines are missing and the updated version of the object does not contain the previous "changed" lines. This behavior is what would have happened previously if you had sent an update to the db and had deliberately omitted the changed lines. (BTW, if you send an update to the db which only has a new "changed" attribute or has all the old "changed" attributes replaced with a new one, a NOOP is the result. The object in the db is not changed). If all the original "changed" information in an inetnum object is not retained, there may be a delay in getting reverse delegation for the associated address space. This is because <auto-inaddr@ripe.net> checks the date when the assignment was originally made and compares it to the assignment window which the local registry had on that date. Thus, the request for reverse delegation is processed manually. So, to keep all the "changed" attributes, do 'whois -c' when you are making a copy of the object before updating it. If you have any questions, please contact <ripe-dbm@ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.
FYI. Ton, Has the new whois version already been installed? We will need the "-c" from now! Regards, Bert RIPE Database Administration wrote:
Dear Colleagues,
Recently, the output of our whois server was modified; the "changed" information is not shown by default. To see it, the new "-c" flag must be used. This requires using the new RIPE whois client.
The "changed" information was removed from the default output of whois after a discussion on the mailing list of the RIPE Database Working Group. This discussion was about the funtionality of the "changed" line. A long-term replacement for it (i.e. timestamping of updates) is planned.
However, there is the possibility that the existing "changed" lines can be accidently deleted from objects. When users want to update an object, they do a whois look-up and re-direct the output into a temporary file. Then, they edit the file and send it to <auto-dbm@ripe.net>. Thus, before the output of the whois server was modified, the update contained all the previous changed fields.
Now, unless the user does "whois -c", the "changed" attributes are not shown. But when users want to update an object, they re-direct a whois look-up into a file, edit it and then send it to the database. However, this time, the "changed" lines are missing and the updated version of the object does not contain the previous "changed" lines. This behavior is what would have happened previously if you had sent an update to the db and had deliberately omitted the changed lines.
(BTW, if you send an update to the db which only has a new "changed" attribute or has all the old "changed" attributes replaced with a new one, a NOOP is the result. The object in the db is not changed).
If all the original "changed" information in an inetnum object is not retained, there may be a delay in getting reverse delegation for the associated address space. This is because <auto-inaddr@ripe.net> checks the date when the assignment was originally made and compares it to the assignment window which the local registry had on that date. Thus, the request for reverse delegation is processed manually.
So, to keep all the "changed" attributes, do 'whois -c' when you are making a copy of the object before updating it.
If you have any questions, please contact <ripe-dbm@ripe.net>.
Regards,
Ambrose Magee ____________________________ RIPE Database Administration.
-- Bert van Hogeloon e-mail: hogeloon@att-unisource.net Voice: +31 23 569 7960 Fax: +31 23 569 7970 AUCS Internet Network Management Center - Hoofddorp e-mail: inmc@att-unisource.net http://www.att-unisource.net
participants (2)
-
Bert van Hogeloon -
RIPE Database Administration