My apologies to all. I don't intend to be a complainer. I'm just trying to understand fully what's going on in the data base. I must say however that I am getting the impression that the value in the created: field for some (many?) inetnum objects may not be entirely reliable, or even entirely consistant with other available historical data. Example: inetnum: 138.201.0.0 - 138.201.255.255 netname: HETZNER-RZ-BLK-ERX4 descr: Server Block country: DE org: ORG-HOA1-RIPE admin-c: HOAC1-RIPE tech-c: HOAC1-RIPE status: LEGACY mnt-by: HOS-GUN mnt-lower: HOS-GUN mnt-routes: HOS-GUN mnt-domains: HOS-GUN created: 1970-01-01T00:00:00Z last-modified: 2019-12-04T13:10:40Z source: RIPE Given that 1970-01-01T00:00:00Z is rather well known to be the beginning of UNIX time (i.e. time: 0) I could not help but be a bit suspicious of the value in the created: field of the record shown above. A quick look at version #1 of the data base object for the 138.201.0.0/16 block suggests that a rather more appropriate value might have been something more like 2003-12-11T17:11:00Z ======================================================================== % Version 1 of object "138.201.0.0 - 138.201.255.255" % This version was a UPDATE operation on 2003-12-11 17:11 inetnum: 138.201.0.0 - 138.201.255.255 remarks: remarks: This inetnum has been transfered as part of the ERX. remarks: It was present in both the ARIN and RIPE databases, so remarks: the information from both databases has been merged. remarks: If you are the mntner of this object, please update it remarks: to reflect the correct information. remarks: remarks: Please see the information for this process: remarks: http://www.ripe.net/db/erx/erx-ip/network-138.html remarks: remarks: **** INFORMATION FROM ARIN OBJECT **** remarks: netname: NETCS-CUST4 descr: netCS Informationstechnik GmbH descr: Feuerbachstrasse 47/49 descr: D-1000 Berlin 41 remarks: country: DE remarks: changed: hostmaster@arin.net 19900523 remarks: changed: hostmaster@arin.net 20010220 remarks: **** INFORMATION FROM RIPE OBJECT **** netname: KIEZ-NET1 descr: Kiez-Net WAN country: DE rev-srv: DNS-A.Kiez.Net rev-srv: DNS-B.Kiez.Net status: ASSIGNED PI mnt-by: KIEZ-MNT source: RIPE # Filtered Am I the only one who thinks so? It is certainly my hope that the value in the created: field should accurately reflect the date & time when any given object was in fact created within the RIPE WHOIS data base. Is there any compelling reason why this should ever not be the case? Regards, rfg
Ronald F. Guilmette via db-wg wrote on 28/05/2021 04:10:
Given that 1970-01-01T00:00:00Z is rather well known to be the beginning of UNIX time (i.e. time: 0) I could not help but be a bit suspicious of the value in the created: field of the record shown above.
It just means that the object predates the time when the RIPE NCC started maintaining accurate logs of object creation / deletion. I.e. clerical issue - nothing suspicious. Nick
In message <b2b8aff9-8dc9-79c4-680b-eb2641d1df01@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
Ronald F. Guilmette via db-wg wrote on 28/05/2021 04:10:
Given that 1970-01-01T00:00:00Z is rather well known to be the beginning of UNIX time (i.e. time: 0) I could not help but be a bit suspicious of the value in the created: field of the record shown above.
It just means that the object predates the time when the RIPE NCC started maintaining accurate logs of object creation / deletion. I.e. clerical issue - nothing suspicious.
Apologies. Bad choice of words on my part. All I meant was that I was "suspicious" that the created: date/time value could be, you know, wrong... which it self-evidently is. Regards, rfg
On Fri, May 28, 2021 at 10:51 AM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote: [...]
All I meant was that I was "suspicious" that the created: date/time value could be, you know, wrong... which it self-evidently is.
And there lies the value. Within the constraints of the format, the RIPE NCC alerted you that additional questions were required. You asked them and got decent answers. I think everyone's a winner here.
In message <CAPfiqjaqD1-q_O=3pNzq9qt0Y-8-bjhC3ejJn59Lzpj-S7doHw@mail.gmail.com>, Leo Vegoda <leo@vegoda.org> wrote:
On Fri, May 28, 2021 at 10:51 AM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
[...]
All I meant was that I was "suspicious" that the created: date/time value could be, you know, wrong... which it self-evidently is.
And there lies the value. Within the constraints of the format, the RIPE NCC alerted you that additional questions were required. You asked them and got decent answers. I think everyone's a winner here.
OK, well, two points: 1) In my sometimes humble opinion, it is suboptimal to have bogus created: values in the public WHOIS records. And my opinion on this point is irrespective of whether the bogus values have been placed there deliberately or accidentally. Furthermore, although the date 01 Jan 1970 has unambiguous significance to me personally... because I've been doing work on *NIX systems for, give or take, the past 40 years... I am not persuaded that every single person who might view the public WHOIS record for the 138.201.0.0/16 object would be so instantly aware of the significance or essential bogosity of that specific value. In short, it's likely confusing for the average man-on-the-street observer. And it isn't as if the job of putting some more meaningful and relevant date/time stamp into the record in this case would be in the least bit difficult. The RIPE WHOIS already contains an ostensibly full history of the registration of this block, and that history quite evidently dates the registration of the block to exactly 2015-09-23 15:10. If there is a reason why 1970-01-01 is, in this instance, a more appropriate value to have in the created: field for this object, as opposed to 2015-09-23, then I am eager to have someone explain that to me. 2) Whereas the created: date/time stamp for the 138.201.0.0/16 object may perhaps be in some sense forgivable, given that it is so self-evidently wrong... at least for anyone with even minimal exposure to *NIX systems... I remain rather entirely perplexed about the created: field values for the 51.155.0.0/16 and 162.55.0.0/16 objects, both of which, as I also noted here yesterday, are clearly marked as "status: LEGACY". Were "LEGACY" allocations still being created as recently as 2015-09-23 and 2019-11-18, respectively? If so, that is certainly news to me, as I suspect it may be also to others. When were the 51.155.0.0/16 and 162.55.0.0/16 blocks actually first registered, either specifically with RIPE or with *any* RIR? And why aren't those original registration dates shown in the respective created: fields for these objects? Forgive me, but it is beginning to appear that I can entirely do away with my local /dev/random device and henceforth just draw as many random numbers as I may need from RIPE WHOIS created: field values. Again, in my humble opinion, this is rather evidently suboptimal. Regards, rfg
Hi Ronald I don't have answers to all your questions but let me throw a few ideas out. First of all the "created:" attribute reflects the date the object was created in the RIPE Database. This may not be the same as 'registered' date. For legacy space there is no concept of allocations and assignments. It was decided many years ago that hierarchies of legacy resources would all have the "status:" 'LEGACY'. If you look around the resource 51.155.0.0/16 you will see many /16 objects with "status: LEGACY" that were 'created' in the database in 2015 - 2019. Maybe a larger legacy resource has been divided up and transferred as a series of /16 legacy resources. The created date on all these new /16 resources would effectively be the transferred date when the object was created in the database. Maybe the original parent legacy resource object has since been deleted. With the current historical query service you cannot query for deleted objects. So it is not easy to check for this situation. I may be completely wrong but these are possibilities you may want to consider. cheers denis co-chair DB-WG On Fri, 28 May 2021 at 23:45, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <CAPfiqjaqD1-q_O=3pNzq9qt0Y-8-bjhC3ejJn59Lzpj-S7doHw@mail.gmail.com>, Leo Vegoda <leo@vegoda.org> wrote:
On Fri, May 28, 2021 at 10:51 AM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
[...]
All I meant was that I was "suspicious" that the created: date/time value could be, you know, wrong... which it self-evidently is.
And there lies the value. Within the constraints of the format, the RIPE NCC alerted you that additional questions were required. You asked them and got decent answers. I think everyone's a winner here.
OK, well, two points:
1) In my sometimes humble opinion, it is suboptimal to have bogus created: values in the public WHOIS records. And my opinion on this point is irrespective of whether the bogus values have been placed there deliberately or accidentally.
Furthermore, although the date 01 Jan 1970 has unambiguous significance to me personally... because I've been doing work on *NIX systems for, give or take, the past 40 years... I am not persuaded that every single person who might view the public WHOIS record for the 138.201.0.0/16 object would be so instantly aware of the significance or essential bogosity of that specific value.
In short, it's likely confusing for the average man-on-the-street observer.
And it isn't as if the job of putting some more meaningful and relevant date/time stamp into the record in this case would be in the least bit difficult. The RIPE WHOIS already contains an ostensibly full history of the registration of this block, and that history quite evidently dates the registration of the block to exactly 2015-09-23 15:10.
If there is a reason why 1970-01-01 is, in this instance, a more appropriate value to have in the created: field for this object, as opposed to 2015-09-23, then I am eager to have someone explain that to me.
2) Whereas the created: date/time stamp for the 138.201.0.0/16 object may perhaps be in some sense forgivable, given that it is so self-evidently wrong... at least for anyone with even minimal exposure to *NIX systems... I remain rather entirely perplexed about the created: field values for the 51.155.0.0/16 and 162.55.0.0/16 objects, both of which, as I also noted here yesterday, are clearly marked as "status: LEGACY".
Were "LEGACY" allocations still being created as recently as 2015-09-23 and 2019-11-18, respectively? If so, that is certainly news to me, as I suspect it may be also to others.
When were the 51.155.0.0/16 and 162.55.0.0/16 blocks actually first registered, either specifically with RIPE or with *any* RIR? And why aren't those original registration dates shown in the respective created: fields for these objects?
Forgive me, but it is beginning to appear that I can entirely do away with my local /dev/random device and henceforth just draw as many random numbers as I may need from RIPE WHOIS created: field values.
Again, in my humble opinion, this is rather evidently suboptimal.
Regards, rfg
participants (4)
-
denis walker -
Leo Vegoda -
Nick Hilliard -
Ronald F. Guilmette