last-modified:, a succesor to changed:
Dear DB Working Group, Assessing the "freshness" of database objects can be a useful component in many business processes, but as it stands today the "changed:" attribute is severely crippled: Eleanor:~ job$ whois -h whois.ripe.net AS15562 | grep changed Eleanor:~ job$ whois -h whois.radb.net AS15562 | grep changed changed: unread@ripe.net 20000101 Eleanor:~ job$ Fantastic! Now we are absolutely none the wiser. :-) I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:". The "last-modified" attribute is set by the whois server software and represents the date and time at which the last succesful modification was received by the server. When a user submits an update for an object in which the attribute is present, the server software will ignore the attribute, insert its own attribute with the current time, and present a warning to the user that the user's version of "last-modified" was ignored. The "last-modified" attribute should be presented by the server software in all types of objects (autnums, poems, etc) for which the server is responsible (e.g. do not touch foreign or mirrored objects). The date and time are represented following the ISO 8601 [1] profile for complete date plus hours, minutes and seconds, always expressed in UTC, including the special UTC designator 'Z'. The "last-modified" attribute should be presented above, but close to the "source:" attribute. The advantage is that the date and time are both human readable and computer parsable! A valid example "last-modified" attribute would be: last-modified: 2014-04-15T13:15:30Z I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation. Kind regards, Job [1] - https://xkcd.com/1179/
Hi, an other good idea Job. The changed lines do not show any valuable information as long as the date can be manually altered. Additionally, your first query did not return any changed lines as these include an e-mail address and are therefore not returned unless you use the -B flag. The changed history can provide information only to the one who maintains the object, as adding or removing changed lines is usualy done according to each company's internal processes/procedures. For example, the best practice is to add a changed line every time you edit an object. I've rarely seen someone following this practice every time they update a RIPE Database object. Plus, adding 100s of lines to an object does not help anyone. Therefore, a +1 from me. cheers, elvis On 15/04/14 15:31, Job Snijders wrote:
Dear DB Working Group,
Assessing the "freshness" of database objects can be a useful component in many business processes, but as it stands today the "changed:" attribute is severely crippled:
Eleanor:~ job$ whois -h whois.ripe.net AS15562 | grep changed Eleanor:~ job$ whois -h whois.radb.net AS15562 | grep changed changed: unread@ripe.net 20000101 Eleanor:~ job$
Fantastic! Now we are absolutely none the wiser. :-)
I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:".
The "last-modified" attribute is set by the whois server software and represents the date and time at which the last succesful modification was received by the server. When a user submits an update for an object in which the attribute is present, the server software will ignore the attribute, insert its own attribute with the current time, and present a warning to the user that the user's version of "last-modified" was ignored. The "last-modified" attribute should be presented by the server software in all types of objects (autnums, poems, etc) for which the server is responsible (e.g. do not touch foreign or mirrored objects).
The date and time are represented following the ISO 8601 [1] profile for complete date plus hours, minutes and seconds, always expressed in UTC, including the special UTC designator 'Z'. The "last-modified" attribute should be presented above, but close to the "source:" attribute.
The advantage is that the date and time are both human readable and computer parsable!
A valid example "last-modified" attribute would be:
last-modified: 2014-04-15T13:15:30Z
I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation.
Kind regards,
Job
[1] - https://xkcd.com/1179/
On 15/04/2014 14:31, Job Snijders wrote:
I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:".
% whois -h whois.ripe.net " --list-versions AS15562" Nick
Heya, On Tue, Apr 15, 2014 at 03:20:12PM +0100, Nick Hilliard wrote:
On 15/04/2014 14:31, Job Snijders wrote:
I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:".
% whois -h whois.ripe.net " --list-versions AS15562"
It is observant of you to mention one of the possible ways to assess the object's freshness. I see value in containing the information within the object itself, this way the information is transferrable when exported to other systems: the dbase dumps on the FTP server or when the information is replicated through NRTM. Kind regards, Job
Hi, On Tue, Apr 15, 2014 at 03:31:36PM +0200, Job Snijders wrote:
A valid example "last-modified" attribute would be:
last-modified: 2014-04-15T13:15:30Z
+1 - looks useful to me, data should already be there anyway. Gives an idea how "stale" a given object is. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
* Job Snijders
Assessing the "freshness" of database objects can be a useful component in many business processes, but as it stands today the "changed:" attribute is severely crippled:
Eleanor:~ job$ whois -h whois.ripe.net AS15562 | grep changed
You'll want to use the "-B" option: $ whois -rB AS15562 | grep changed changed: hostmaster@ripe.net 20140224 [....] changed: job@instituut.net 20140204
I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:".
Makes sense to me. While we're at it, might as well add a similar "created:" for much the same reasons. IP Analyser, asused, the IPRAs, etc. are looking at the earliest changed: line present in order to infer the registration date, but since there's no requirement to retain old changed: lines when submitting updates that doesn't necessarily align very well with reality either. (Case in point: 87.238.48.64/28.) Tore
On Wed, Apr 16, 2014 at 08:05:08AM +0200, Tore Anderson wrote:
Assessing the "freshness" of database objects can be a useful component in many business processes, but as it stands today the "changed:" attribute is severely crippled:
Eleanor:~ job$ whois -h whois.ripe.net AS15562 | grep changed
You'll want to use the "-B" option:
As far as I understand there is a limit [1] to how often you can query the Whois Server before ending up with a (temporarily) ban.
I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:".
Makes sense to me.
While we're at it, might as well add a similar "created:" for much the same reasons.
If others agree that a "created:" attribute (with similar syntax as "last-modified:") is a useful feature, it should be added. I myself don't immediately see how I would use "created:" in an operational context. Group, please comment on both "last-modified" and "created" attributes! Kind regards, Job [1] - http://www.ripe.net/data-tools/support/documentation/aup
In iks.lists.ripe.db, you wrote:
If others agree that a "created:" attribute (with similar syntax as "last-modified:") is a useful feature, it should be added. I myself don't immediately see how I would use "created:" in an operational context.
"created:" has a drawback and a real use case for me. The drawback is, that some strange people harvest the email addresses from this field in order to send spam. Because my email address is unchanged since decades, I do not really have a problem with. The benefit I do gain from this field is documentation. Who was involved at what time which this customer? In most cases the customers do not have any clue about their assignments, and even in most companies not every change is documented that clearly, so that any question "Why the hell is this so?" can be answered immediatly. So the real benefit is exactly the reason why this field exists: Documentation. Ah and just another gimmick: Due to the checks of the RIPE mailrobot, always the most recent copy of the object data is modified, even if the local database was bypassed by any event (i.e. modification by RIPE NCC). So please keep the changed: field and report an "last-modified" comment at the beginning of the Whois report as you currently do with abuse-mailbox.
Job, On Tue, 15 Apr 2014 15:31:36 +0200 Job Snijders <job@instituut.net> wrote:
I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:".
I'm not opposed. In fact I have supported such efforts in the past, which have always met with a universal "meh" from the working group. ;) However it seems you have good support now. :) One possible issue: I have been told that some LIRs don't want their competition seeing the dates of their database activity for whatever reason. ("changed:" does not reveal this, as only a single you can literally put in whatever date you want there, although there may be checks to make sure that it is within the last century or so and not too far in the future.) I hope that this is a minor concern, but maybe it is good to engage with the appropriate working group(s) early in this process to avoid any last-minute surprise objections. I'm thinking an FYI to address policy and NCC services might be the right approach, but maybe Wilfried can advise better. Cheers, -- Shane
On Wed, Apr 16, 2014 at 12:41:43PM +0200, Shane Kerr wrote:
Job Snijders <job@instituut.net> wrote:
I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:".
One possible issue: I have been told that some LIRs don't want their competition seeing the dates of their database activity for whatever reason.
I cannot imagine how one would benefit from hiding this information, also: the data is already public anyway, today :-) To quote Nick:
% whois -h whois.ripe.net " --list-versions AS15562"
I hope that this is a minor concern, but maybe it is good to engage with the appropriate working group(s) early in this process to avoid any last-minute surprise objections. I'm thinking an FYI to address policy and NCC services might be the right approach, but maybe Wilfried can advise better.
OK. But let's first reach some consensus in this group. Comments from Wilfriend are always welcome. Kind regards, Job
On 16/04/2014 12:23, Job Snijders wrote:
OK. But let's first reach some consensus in this group. Comments from Wilfriend are always welcome.
I'm good with a last-modified: line, or equivalent. Nick
Dear colleagues Perhaps if I can clarify some of the issues here. I already see some of the old arguments being raised about spam and not wanting some information to be available to all. Currently we have a list of multiple "changed:" attributes that may look something like this: changed: unread@user.com 20100302 changed: hostmaster@ripe.net 20101115 changed: me@here.org 20140201 this implies that the object was created in March 2010 and has been updated twice. But it may have been created in 2003 and updated 10 times. The content of these attributes is almost entirely at the discretion of the user. There may be many reasons why the full change history is not shown. But now we have the query option '--list-versions' which would show the complete history of this object as: rev# Date Op. 1 2003-03-17 13:15 ADD/UPD 2 2003-04-12 08:32 ADD/UPD 3 2003-05-22 13:20 ADD/UPD 4 2004-10-22 14:43 ADD/UPD 5 2004-10-31 03:08 ADD/UPD 6 2006-02-21 16:46 ADD/UPD 7 2009-12-02 13:27 ADD/UPD 8 2009-12-02 13:49 ADD/UPD 9 2010-03-17 15:00 ADD/UPD 10 2011-02-17 12:11 ADD/UPD 11 2013-03-19 16:24 ADD/UPD So the "changed:" attributes may now simply provide inaccurate and confusing information, when the true information is easily available. Each version of this object can also be viewed with the query option '--show-version n'. The "changed:" attribute also 'requires' an email address. This has been complained about for years because of the harvesting and abuse potential. New attribute(s) without the requirement for an email address completely removes this avenue for abuse. Data maintainers can add whatever additional information they wish about who did an update in "remarks:". New attributes as Job and others have suggested for the above object could look like this: remarks: created by sales (RD132-RIPE) remarks: updated by customer support (dw-ripe) created: 2003-03-17T13:15:30Z last-modified: 2013-03-19T16:24:30Z with the optional "remarks:" added by the maintainer and the time stamps auto-generated by the update software. If necessary the RIPE NCC can generate the created and last modified dates for every object currently in the RIPE Database. Hope this helps with the discussion. Regards Denis Walker Business Analyst RIPE NCC Database Team On 16/04/2014 13:26, Nick Hilliard wrote:
On 16/04/2014 12:23, Job Snijders wrote:
OK. But let's first reach some consensus in this group. Comments from Wilfriend are always welcome. I'm good with a last-modified: line, or equivalent.
Nick
I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation. No objections to an automatically enforced last-modified attribute, but
On Apr 15, Job Snijders <job@instituut.net> wrote: then I would demote changed to an optional attribute to allow removing duplicate information. I already use changed this way, by only keeping the last one. -- ciao, Marco
On Wed, Apr 16, 2014 at 04:33:12PM +0200, Marco d'Itri wrote:
On Apr 15, Job Snijders <job@instituut.net> wrote:
I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation.
No objections to an automatically enforced last-modified attribute, but then I would demote changed to an optional attribute to allow removing duplicate information. I already use changed this way, by only keeping the last one.
I think making changed: optional is good addition to the proposal. Kind regards, Job
Dear Job If we implement attributes with generated values is there any point in keeping the "changed:" attribute at all? It: -is user set to a vast range of dates (user's choice) with as many or few instances as you wish -is unreliable and possibly miss-leading to anyone else -will become, even if correct, a duplication of both the generated values and --list-versions output -requires mandatory email address -invites abuse Maybe it could be deprecated if the proposed attributes are implemented? Regards Denis Walker Business Analyst RIPE NCC Database Team On 17/04/2014 13:38, Job Snijders wrote:
On Wed, Apr 16, 2014 at 04:33:12PM +0200, Marco d'Itri wrote:
On Apr 15, Job Snijders <job@instituut.net> wrote:
I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation. No objections to an automatically enforced last-modified attribute, but then I would demote changed to an optional attribute to allow removing duplicate information. I already use changed this way, by only keeping the last one. I think making changed: optional is good addition to the proposal.
Kind regards,
Job
On 17/04/2014 12:58, Denis Walker wrote:
If we implement attributes with generated values is there any point in keeping the "changed:" attribute at all? [...] Maybe it could be deprecated if the proposed attributes are implemented?
works for me. Nick
On Thu, Apr 17, 2014 at 01:58:39PM +0200, Denis Walker wrote:
If we implement attributes with generated values is there any point in keeping the "changed:" attribute at all?
You are right. "last-modified:" makes "changed:" entirely redundant, would only serve to still my sense of nostalgia. I support removing the "changed:" attribute from all RIPE objects. Kind regards, Job
Hi, On Thu, Apr 17, 2014 at 02:55:44PM +0200, Job Snijders wrote:
On Thu, Apr 17, 2014 at 01:58:39PM +0200, Denis Walker wrote:
If we implement attributes with generated values is there any point in keeping the "changed:" attribute at all?
You are right. "last-modified:" makes "changed:" entirely redundant, would only serve to still my sense of nostalgia. I support removing the "changed:" attribute from all RIPE objects.
Nah, I do not support that. Leave my objects alone, if only for my nostalgia. Making changed: entirely optional, and possibly recommend against using it for new entries, that is something I would be fine with. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard 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 all,
Making changed: entirely optional, and possibly recommend against using it for new entries, that is something I would be fine with.
I fully agree with Gert here. I am sure deleting the "changed:" attribute would break quite a few scripts. Best regards, Janos
Gert Doering -- NetMaster
On Thu, Apr 17, 2014 at 03:25:59PM +0200, Janos Zsako wrote:
Dear all,
Making changed: entirely optional, and possibly recommend against using it for new entries, that is something I would be fine with.
I fully agree with Gert here. I am sure deleting the "changed:" attribute would break quite a few scripts.
When an attribute ends up on the to-be-deprecated list, the community would be given ample time and notice before the change would actually be implemented. Like with referral-by, a procedure such as "inform" -> "warn" -> "error" spread over a few months could be used to make the community aware a change is coming. If you have scripts that rely on a modification date as expressed in "changed:", it would be a rather magnificant upgrade to be able to use "last-modified:" as that attribute is truthful and offers higher resolution. :-) Kind regards, Job
Dear Janos As Job pointed out we can phase in such a change. So if it is decided to remove the "changed:" atribute, as well as communicating such a change by various means, we could adjust the software so that any object submitted for update containing a "changed:" attribute will have it stripped out by the software with a Warning message added to the ack response. This would prevent any update script from failing. If anyone has scripts that read the "changed:" values and expect to find them, these scripts would break anyway if the attribute is made optional and someone chooses to remove them from their data. Regards Denis Walker Business Analyst RIPE NCC Database Team On 17/04/2014 15:25, Janos Zsako wrote:
Dear all,
Making changed: entirely optional, and possibly recommend against using it for new entries, that is something I would be fine with.
I fully agree with Gert here. I am sure deleting the "changed:" attribute would break quite a few scripts.
Best regards, Janos
Gert Doering -- NetMaster
Dear Denis,
As Job pointed out we can phase in such a change. So if it is decided to remove the "changed:" atribute, as well as communicating such a change by various means, we could adjust the software so that any object submitted for update containing a "changed:" attribute will have it stripped out by the software with a Warning message added to the ack response. This would prevent any update script from failing.
Good idea. If this is a warning only, that does not prevent the update, I think it addresses my concerns.
If anyone has scripts that read the "changed:" values and expect to find them, these scripts would break anyway if the attribute is made optional and someone chooses to remove them from their data.
Agreed. Your other comment about the possibility to delete the "changed:" attributes from all objects, and therefore make inaccessible many e-mail addresses that could otherwise attract spam, is something that lets me think we better deprecate this attribute. I guess the historical values of "changed:" would still be retrievable with '--show-version n', but at least they would not appear on the "live" objects. Best regards, Janos
Regards Denis Walker Business Analyst RIPE NCC Database Team
On 17/04/2014 15:25, Janos Zsako wrote:
Dear all,
Making changed: entirely optional, and possibly recommend against using it for new entries, that is something I would be fine with.
I fully agree with Gert here. I am sure deleting the "changed:" attribute would break quite a few scripts.
Best regards, Janos
Gert Doering -- NetMaster
Dear Gert There is one downside to keeping the "changed:" attribute as optional. The RIPE NCC can remove all "changed:" attributes from all objects if required. But we can't easily do a selective removal for some users and not for others. So if it is kept as optional, those users who might prefer to clean the RIPE Database of many email addresses in possibly tens of thousands of objects will basically have to do it themselves. Regards Denis Walker Business Analyst RIPE NCC Database Team On 17/04/2014 15:20, Gert Doering wrote:
Hi,
On Thu, Apr 17, 2014 at 02:55:44PM +0200, Job Snijders wrote:
On Thu, Apr 17, 2014 at 01:58:39PM +0200, Denis Walker wrote:
If we implement attributes with generated values is there any point in keeping the "changed:" attribute at all? You are right. "last-modified:" makes "changed:" entirely redundant, would only serve to still my sense of nostalgia. I support removing the "changed:" attribute from all RIPE objects. Nah, I do not support that. Leave my objects alone, if only for my nostalgia.
Making changed: entirely optional, and possibly recommend against using it for new entries, that is something I would be fine with.
Gert Doering -- NetMaster
In iks.lists.ripe.db, you wrote:
not for others. So if it is kept as optional, those users who might prefer to clean the RIPE Database of many email addresses in possibly tens of thousands of objects will basically have to do it themselves.
How about a button in the LIR portal? "Remove all changed lines from all objects -i mnt-by"?
Hi, On Thu, Apr 17, 2014 at 04:02:12PM +0200, Lutz Donnerhacke wrote:
In iks.lists.ripe.db, you wrote:
not for others. So if it is kept as optional, those users who might prefer to clean the RIPE Database of many email addresses in possibly tens of thousands of objects will basically have to do it themselves.
How about a button in the LIR portal? "Remove all changed lines from all objects -i mnt-by"?
I like that. (I was thinking along the same lines but had no really good idea how to communicate the subset of objects to be modified towards the NCC). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Thu, Apr 17, 2014 at 04:02:12PM +0200, Lutz Donnerhacke wrote:
In iks.lists.ripe.db, you wrote:
not for others. So if it is kept as optional, those users who might prefer to clean the RIPE Database of many email addresses in possibly tens of thousands of objects will basically have to do it themselves.
How about a button in the LIR portal? "Remove all changed lines from all objects -i mnt-by"?
+1 Of course, this still leave us with some corner cases like person objects without any maintainer. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On Thu, Apr 17, 2014 at 05:22:15PM +0200, Piotr Strzyzewski wrote:
On Thu, Apr 17, 2014 at 04:02:12PM +0200, Lutz Donnerhacke wrote:
In iks.lists.ripe.db, you wrote:
not for others. So if it is kept as optional, those users who might prefer to clean the RIPE Database of many email addresses in possibly tens of thousands of objects will basically have to do it themselves.
How about a button in the LIR portal? "Remove all changed lines from all objects -i mnt-by"?
+1
Of course, this still leave us with some corner cases like person objects without any maintainer.
I think this approach would be quite a clutch with no benefits. Aside from 'nostalgia' are there any operational reasons not to deprecate the "changed:" attribute? Keeping entirely redundant attributes for the sake of keeping them, complicates database operations & usage. Kind regards, Job
On Thu, Apr 17, 2014 at 05:29:33PM +0200, Job Snijders wrote:
On Thu, Apr 17, 2014 at 05:22:15PM +0200, Piotr Strzyzewski wrote:
On Thu, Apr 17, 2014 at 04:02:12PM +0200, Lutz Donnerhacke wrote:
In iks.lists.ripe.db, you wrote:
not for others. So if it is kept as optional, those users who might prefer to clean the RIPE Database of many email addresses in possibly tens of thousands of objects will basically have to do it themselves.
How about a button in the LIR portal? "Remove all changed lines from all objects -i mnt-by"?
+1
Of course, this still leave us with some corner cases like person objects without any maintainer.
I think this approach would be quite a clutch with no benefits.
Aside from 'nostalgia' are there any operational reasons not to deprecate the "changed:" attribute?
1. Breaking some scripts (already mentioned). 2. Some people keep real history of changes using this attribute. If this is going to be deprecated, they would be forced to rewrite some scripts.
Keeping entirely redundant attributes for the sake of keeping them, complicates database operations & usage.
Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear Piotr, On Thu, Apr 17, 2014 at 05:36:21PM +0200, Piotr Strzyzewski wrote:
1. Breaking some scripts (already mentioned).
Scripts depending on the existance of "changed:" when parsing an object will break anyway if the attribute is made optional, so I fail to see the point. Patching a script to accept ISO8601 string instead of "20140101" should be trivial task for most companies when given a few months notice. I expect any company with a dependency on the RIPE Whois Database to invest at least a few hours per year to maintain the software driving their operations. As Denis stated earlier, scripts /updating/ the RIPE database need no change as the attribute will just be ignored by the RIPE Whois software.
2. Some people keep real history of changes using this attribute. If this is going to be deprecated, they would be forced to rewrite some scripts.
The history is already recorded, and automatically available through the use of the --list-versions and --show-version flags. This is real history as it can show you the actual changes between versions of an object. When people deem it necessary to publically record who or what made the last change, a "remarks:" attribute would be appropiate. Kind regards, Job
On Thu, Apr 17, 2014 at 05:59:30PM +0200, Job Snijders wrote: Dear Job
On Thu, Apr 17, 2014 at 05:36:21PM +0200, Piotr Strzyzewski wrote:
1. Breaking some scripts (already mentioned).
Scripts depending on the existance of "changed:" when parsing an object will break anyway if the attribute is made optional, so I fail to see the point. Patching a script to accept ISO8601 string instead of "20140101" should be trivial task for most companies when given a few months notice. I expect any company with a dependency on the RIPE Whois Database to invest at least a few hours per year to maintain the software driving their operations.
Good point.
As Denis stated earlier, scripts /updating/ the RIPE database need no change as the attribute will just be ignored by the RIPE Whois software.
Although I expect that at some point of time, the software will be changed to throw an error.
2. Some people keep real history of changes using this attribute. If this is going to be deprecated, they would be forced to rewrite some scripts.
The history is already recorded, and automatically available through the use of the --list-versions and --show-version flags. This is real
And this is not true for every object: $ whois -- --list-versions PS1393-RIPE|grep available % History not available for PERSON and ROLE objects.
history as it can show you the actual changes between versions of an object. When people deem it necessary to publically record who or what made the last change, a "remarks:" attribute would be appropiate.
Which exactly mean that they have to rewrite some scripts. And just to be clear - I vote for making this attribute deprecated. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi, transforming all but the last changed: attributes into remarks: would be the best way I would see this implementation being done. This way scripts that use the changed attribute won't break unless the maintainer of the object decides to remove the (now optional) changed attribute. Additionally, I think that making changed: optional is a good idea. I don't think that by removing all the changed lines the RIPE Database will be cleaner.. I think we should let every maintainer decide if he wants to keep the changed: lines as history of/in the object (in the remarks: lines) or remove them at a later date. my 2 cents, elvis On 17/04/14 18:23, Piotr Strzyzewski wrote:
On Thu, Apr 17, 2014 at 05:59:30PM +0200, Job Snijders wrote:
Dear Job
On Thu, Apr 17, 2014 at 05:36:21PM +0200, Piotr Strzyzewski wrote:
1. Breaking some scripts (already mentioned). Scripts depending on the existance of "changed:" when parsing an object will break anyway if the attribute is made optional, so I fail to see the point. Patching a script to accept ISO8601 string instead of "20140101" should be trivial task for most companies when given a few months notice. I expect any company with a dependency on the RIPE Whois Database to invest at least a few hours per year to maintain the software driving their operations. Good point.
As Denis stated earlier, scripts /updating/ the RIPE database need no change as the attribute will just be ignored by the RIPE Whois software. Although I expect that at some point of time, the software will be changed to throw an error.
2. Some people keep real history of changes using this attribute. If this is going to be deprecated, they would be forced to rewrite some scripts. The history is already recorded, and automatically available through the use of the --list-versions and --show-version flags. This is real And this is not true for every object:
$ whois -- --list-versions PS1393-RIPE|grep available % History not available for PERSON and ROLE objects.
history as it can show you the actual changes between versions of an object. When people deem it necessary to publically record who or what made the last change, a "remarks:" attribute would be appropiate. Which exactly mean that they have to rewrite some scripts.
And just to be clear - I vote for making this attribute deprecated.
Piotr
Hi, On Thu, Apr 17, 2014 at 06:37:33PM +0200, Elvis Velea wrote:
transforming all but the last changed: attributes into remarks: would be the best way I would see this implementation being done.
I think that this is a very poor idea, tbh - it would keep the e-mail addresses, and would now make them clearly visible all the time. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert, On 17/04/14 18:48, Gert Doering wrote:
Hi,
On Thu, Apr 17, 2014 at 06:37:33PM +0200, Elvis Velea wrote:
transforming all but the last changed: attributes into remarks: would be the best way I would see this implementation being done. I think that this is a very poor idea, tbh - it would keep the e-mail addresses, and would now make them clearly visible all the time. you're right, I stand corrected.
cheers, elvis
You are right. "last-modified:" makes "changed:" entirely redundant, would only serve to still my sense of nostalgia. I support removing the "changed:" attribute from all RIPE objects.
I fully see that reasoning .. I would support that change as well. I also support the implementation of last-modified: as suggested by Job. Kind regards, Erik Bais
On Thu, Apr 17, 2014 at 01:58:39PM +0200, Denis Walker wrote: Dear All
If we implement attributes with generated values is there any point in keeping the "changed:" attribute at all?
It: -is user set to a vast range of dates (user's choice) with as many or few instances as you wish -is unreliable and possibly miss-leading to anyone else -will become, even if correct, a duplication of both the generated values and --list-versions output -requires mandatory email address -invites abuse
Maybe it could be deprecated if the proposed attributes are implemented?
Although I see some idea behind keeping the "changed:" attribute (at least as optional one), I fully support making it deprecated if the proposal of implementing last-modified: would be accepted. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 17/04/14 12:58, Denis Walker wrote:
Dear Job
If we implement attributes with generated values is there any point in keeping the "changed:" attribute at all?
It: -is user set to a vast range of dates (user's choice) with as many or few instances as you wish -is unreliable and possibly miss-leading to anyone else -will become, even if correct, a duplication of both the generated values and --list-versions output -requires mandatory email address -invites abuse
Maybe it could be deprecated if the proposed attributes are implemented?
I feel that this would make sense. The changed: attribute actually seems to convey very little in the way of concrete data.
Regards Denis Walker Business Analyst RIPE NCC Database Team
On 17/04/2014 13:38, Job Snijders wrote:
On Wed, Apr 16, 2014 at 04:33:12PM +0200, Marco d'Itri wrote:
On Apr 15, Job Snijders<job@instituut.net> wrote:
I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation. No objections to an automatically enforced last-modified attribute, but then I would demote changed to an optional attribute to allow removing duplicate information. I already use changed this way, by only keeping the last one. I think making changed: optional is good addition to the proposal.
Kind regards,
Job
+1 Andreas Larsen IP-Only AB | Postadress: 753 81 UPPSALA | Besöksadress Uppsala: S:t Persg 6 Besöksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70 843 10 56 www.ip-only.se 15 apr 2014 kl. 15:31 skrev Job Snijders <job@instituut.net>:
Dear DB Working Group,
Assessing the "freshness" of database objects can be a useful component in many business processes, but as it stands today the "changed:" attribute is severely crippled:
Eleanor:~ job$ whois -h whois.ripe.net AS15562 | grep changed Eleanor:~ job$ whois -h whois.radb.net AS15562 | grep changed changed: unread@ripe.net 20000101 Eleanor:~ job$
Fantastic! Now we are absolutely none the wiser. :-)
I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:".
The "last-modified" attribute is set by the whois server software and represents the date and time at which the last succesful modification was received by the server. When a user submits an update for an object in which the attribute is present, the server software will ignore the attribute, insert its own attribute with the current time, and present a warning to the user that the user's version of "last-modified" was ignored. The "last-modified" attribute should be presented by the server software in all types of objects (autnums, poems, etc) for which the server is responsible (e.g. do not touch foreign or mirrored objects).
The date and time are represented following the ISO 8601 [1] profile for complete date plus hours, minutes and seconds, always expressed in UTC, including the special UTC designator 'Z'. The "last-modified" attribute should be presented above, but close to the "source:" attribute.
The advantage is that the date and time are both human readable and computer parsable!
A valid example "last-modified" attribute would be:
last-modified: 2014-04-15T13:15:30Z
I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation.
Kind regards,
Job
[1] - https://xkcd.com/1179/
Dear Working Group, This proposal has lingered around on the mailinglist for some time now, and discussion seems to be finished. I'd like to offer this summary: Add two and remove one attributes to all objects with source: RIPE. * Addition of a "last-modified" attribute, example: last-modified: 2014-04-15T13:15:30Z * Addition of a "created" attribute, example: created: 2014-04-15T13:15:30Z * Deprecation of the "changed:" attribute (in phases!). Object updates that include a "changed:" line should receive a soft warning and not a blocking error, this way existing scripts need not be modified. In some future release 'changed:' lines will no longer be published by the Whois Server, completing the deprecation. The 'last-modified:' and 'created:' attributes will be automatically generated by the RIPE Whois Software. When clients include them in updates the Whois Server will ignore them. Chairs, can we move this forward? Kind regards, Job
On 27/05/14 14:37, Job Snijders wrote:
Dear Working Group,
This proposal has lingered around on the mailinglist for some time now, and discussion seems to be finished. I'd like to offer this summary:
Add two and remove one attributes to all objects with source: RIPE.
* Addition of a "last-modified" attribute, example: last-modified: 2014-04-15T13:15:30Z * Addition of a "created" attribute, example: created: 2014-04-15T13:15:30Z * Deprecation of the "changed:" attribute (in phases!).
Object updates that include a "changed:" line should receive a soft warning and not a blocking error, this way existing scripts need not be modified. In some future release 'changed:' lines will no longer be published by the Whois Server, completing the deprecation.
The 'last-modified:' and 'created:' attributes will be automatically generated by the RIPE Whois Software. When clients include them in updates the Whois Server will ignore them.
Chairs, can we move this forward?
Checking back on the discussion I think that consensus has been reached on this proposal. RIPE NCC can you proceed with it please? Nigel
Dear working group, Following the consensus call we looked into the proposal to replace “changed” with “created” and “last-modified”. Part of this proposal involves the removal of an attribute that is currently mandatory, and this has a potential big impact on both consumers (querying for objects) and producers (creating/updating objects) of the RIPE DB. To make sure that everything goes as smoothly as possible we therefore propose a multi phase approach allowing for ample testing and communication, and migration from using the current attribute to the new ones. Before starting implementation we would like to discuss this proposal with the WG, both on list and in person at RIPE 69. The dates mentioned below should be regarded as provisional in that context. Once we have the okay from the working group to proceed we will communicate a finalised implementation plan. Also, we will communicate about each phase separately in future. Phase 1 and 2 to the mailing list, phase 3 can be discussed on the mailing list, and in person at RIPE 70. Phase 1: Introduce new attributes: “created” and “last-modified” ======================================================================== Shortly after RIPE 69 26 Nov 2014: RC 10 Dec 2014: Production (2 weeks of RC) - “last-modified” & “created” are added to output (adding new attributes is RFC compliant, parsers should ignore it if they don't understand) - “changed” is accepted as-is today Users of the RIPE DB that are using the “changed” attribute should migrate their tools to rely on “created” and “last-modified” instead during this phase. Phase 2: “changed” becomes optional ======================================================================== Two months after RIPE 69 21 Jan 2015: RC 4 Mar 2015: Production (6 weeks of RC) - When an object is submitted with “changed" attributes a WARNING is generated, but the update is accepted - When an object is submitted _without_ the “changed” attribute it is accepted - The “changed” attribute is marked as 'optional' in the RPSL schema Users of the RIPE DB that are still using the “changed” attribute will start to see objects without any “changed” attributes. They are once more encouraged to migrate to using “created” and “last-modified” instead. Users are encouraged to stop including “changed” attributes when they submit objects. Phase 3: “changed” is completely deprecated ======================================================================== Two months after RIPE 70 27 May 2015: RC 8 Jul 2015: Production (6 weeks of RC) - The “changed” attribute will be removed from all outputs: whois, restful, NRTM, ftpdump - When an object is submitted with “changed" attributes a ERROR is generated, and the update is rejected - The “changed” attribute is removed from the RPSL schema As the final step of deprecating the “changed” attribute all users are forced to stop using it. This means that users who are still submitting “changed” attributes, will start seeing their updates rejected at this point (after having received warnings for 4 months). This step is necessary as the WG agreed that the “changed” attribute is no longer needed. Kind regards, Tim Bruijnzeels Assistent Manager Software Engineering RIPE NCC
Hi all, On Thu, Sep 11, 2014 at 05:20:07PM +0200, Tim Bruijnzeels wrote:
Following the consensus call we looked into the proposal to replace “changed” with “created” and “last-modified”.
Part of this proposal involves the removal of an attribute that is currently mandatory, and this has a potential big impact on both consumers (querying for objects) and producers (creating/updating objects) of the RIPE DB. To make sure that everything goes as smoothly as possible we therefore propose a multi phase approach allowing for ample testing and communication, and migration from using the current attribute to the new ones.
Phase 1: Introduce new attributes: “created” and “last-modified” Phase 2: “changed” becomes optional Phase 3: “changed” is completely deprecated
Disclosure: I sat down with Tim to create this implementation timeline. The main advantages of the proposed timeline are: - Two RIPE meetings to warn/inform people - Consumer scripts might break after 3 months the announcements (because the attribute was mandatory) - Concurrent existence of "last-modified" and "changed" attributes - Publish scripts might break ~ 8 months after the first announcements - In total there will be 5 months of warning-output in email/api/webupdates before attribute is entirely deprecated I think this is a reasonable, careful, strategy. We can re-use this schedule when we deprecate more attributes in the future. Kind regards, Job
On Thu, Sep 11, 2014 at 05:20:07PM +0200, Tim Bruijnzeels wrote:
Following the consensus call we looked into the proposal to replace ?changed? with ?created? and ?last-modified?.
[cut] I like this plan/proposal/schedule. It is extremely careful, which is good in this situation. One question: are you going to introduce --list-versions and --show-version for those object which doesn't support them now. This could lead to some problems (data protection, data retention). However this could be also more consistent with the removal of the changed lines. Would you elaborate on that? Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi Piotr, Thank you for your feedback. On 12 Sep 2014, at 11:36, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
On Thu, Sep 11, 2014 at 05:20:07PM +0200, Tim Bruijnzeels wrote:
Following the consensus call we looked into the proposal to replace ?changed? with ?created? and ?last-modified?.
[cut]
I like this plan/proposal/schedule. It is extremely careful, which is good in this situation. One question: are you going to introduce --list-versions and --show-version for those object which doesn't support them now. This could lead to some problems (data protection, data retention). However this could be also more consistent with the removal of the changed lines. Would you elaborate on that?
In this case the actual changes should not be public, for the reasons you mention. However, we can look into providing more detailed history to authorised maintainers of such objects. Would this add value for you? The idea would be that as an ‘owner’ you have full insight into the history, and you can use remarks for anything you would wish to share with the public. Kind regards, Tim Bruijnzeels Assistent Manager Software Engineering RIPE NCC
On Tue, Sep 16, 2014 at 02:42:10PM +0200, Tim Bruijnzeels wrote: Hi Tim
On 12 Sep 2014, at 11:36, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
On Thu, Sep 11, 2014 at 05:20:07PM +0200, Tim Bruijnzeels wrote:
Following the consensus call we looked into the proposal to replace ?changed? with ?created? and ?last-modified?.
[cut]
I like this plan/proposal/schedule. It is extremely careful, which is good in this situation. One question: are you going to introduce --list-versions and --show-version for those object which doesn't support them now. This could lead to some problems (data protection, data retention). However this could be also more consistent with the removal of the changed lines. Would you elaborate on that?
In this case the actual changes should not be public, for the reasons you mention.
However, we can look into providing more detailed history to authorised maintainers of such objects. Would this add value for you? The idea would be that as an ?owner? you have full insight into the history, and you can use remarks for anything you would wish to share with the public.
I can live with the remarks lines. :) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (15)
-
Andreas Larsen -
Denis Walker -
Elvis Velea -
Erik Bais -
Gert Doering -
Janos Zsako -
Job Snijders -
Lutz Donnerhacke -
md＠Linux.IT -
Nick Hilliard -
Nigel Titley -
Piotr Strzyzewski -
Shane Kerr -
Tim Bruijnzeels -
Tore Anderson