Hi John! Thank's for raising that issue. = davidk@isi.edu writes: = * = * John, = * = * I am afraid that the people that forget the "source:" field are the same = * people that send a "source: RADB/MCI/whatever" to the RIPE database. You = * will thus get more consistency problems if those people find out about = * the possibility to omit the "source:" field. We are dealing with a set of = * logical different databases and I think that it is better that people = * *know* about this to avoid all the possible confusion about where their = * data is stored and mistakes made by people that have to deal with more = * databases then just the RIPE one. = =The letting them know would occur when they recieve warnings, or in =the case of an incorrect "source:" have the update fail. One of the reasons why we insist on a source: field is the dream(?) of eventually having a system where we can submit updates to our local/favourite/whatever registry (db update mechanism) and have the update automatically forwarded to the "correct" registry. Of course, it's still a dream... I'd like to get input whether the user community would prefer more "comfort" locally and to trade in some future functionality... =People are clearly told that they need to put in a source field in the =documents, the ones I see most are where people forget to add a source =field, even if they know about the different databases. They just =forget, a warning should be enough for these people to remember =next time. I tend to agree. = * Another problem is that many people don't really like the automatic = * fiddling with their objects which also makes it very hard to do things = * (in the future) like signing objects by the user itself and storing them = * as-is including the signature in the database. = =We do this already with some fields. inetnum gets changed if they =send in ... = =inetnum: 194.0.1.0 = =or = =inetnum: 194.0.1.0/24 = =... to = =inetnum: 194.0.1.0 - 194.0.1.255 That's an interesting aspect. (Actually, only the "classful" update would be expanded, isn't it?) Which indeed adds another facette to an authentication environment ;-) But we might be able to solve that by disallowing "classful" *updates* as soon as we offer authentication. Please note that I don't see a problem in *replacing* any existing "classful" object by a signed new object. Or do I miss something?

The changed field can also be fiddled with, i.e if the date is in the future.

I think this should be solved while implementing the automatic UTC (and source) tagging. As soon as we have that in place, I do no longer see a reason to touch any user-supplied data in the changed field(s).

These are both cases where the database needs a particular format and can therefor make the change. I would suggest that the "source:" could be a similar case.

Is there a reason that I am missing why the "source:" differs from these when it comes to "signatures" etc.

That's true. Although I'd like to limit "automatic" modifications, anyway.

* On the other hand I really like this since I am a lazy person and I have * to admit that I have a local db running as my address book that does * exactly the thing that you propose ...

Me too! (Ok, get these flame throwers set up :-) Honestly, how about offering that for as long as there is no authentication interaction? As soon as we hit the wall we might have a solution ready or we might have to *not* offer that comfort for signed or checksummed updates? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------