Proposal for db change

  Hi John!
  
  Thank's for raising that issue.

= davidk at 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 at 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
 --------------------------------------------------------------------------