Hi John!
Thank's for raising that issue.
= davidk(a)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(a)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
--------------------------------------------------------------------------
