Hello folks, I was sitting here getting annoyed at people who forget to add "source:" fields when I had a thought; Would it be useful to have the "source:" field added automatically when people forget it? I am assuming here that all updates to auto-dbm@ripe.net should contain "source: RIPE". The update could take place and a warning could be issued. _______________________ Warning "source:" field missing The field "source: RIPE" has been added to your object. _______________________ My experience is that many people forget to add "source:" fields and the objects get rejected. As the field should always be the same would it not be useful to update it and generate a warning? Your opinions would be appreciated, Kind regards, John Crain RIPE NCC
John, John LeRoy Crain writes:
I was sitting here getting annoyed at people who forget to add "source:" fields when I had a thought;
Would it be useful to have the "source:" field added automatically when people forget it?
I am assuming here that all updates to auto-dbm@ripe.net should contain "source: RIPE".
The update could take place and a warning could be issued.
_______________________
Warning
"source:" field missing
The field "source: RIPE" has been added to your object.
_______________________
My experience is that many people forget to add "source:" fields and the objects get rejected. As the field should always be the same would it not be useful to update it and generate a warning?
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. 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. 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 ... David K. ---
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. 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. * 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 The changed field can also be fiddled with, i.e if the date is in the future. 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. * 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 ... Kind regards, John Crain RIPE NCC * * David K. * ---
John, John LeRoy Crain writes:
davidk@isi.edu writes: * 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.
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.
My experience was that warnings don't help much :-( since many people don't even look at their ACK messages. An error usually gives the best incentive to fix things and I would rather deal with somebody that tells that there was an error with a missing 'source:' field then to try to find an object that was sent to the wrong database or even worse is present in more then one database which can give interesting problems when you use the routing registry to configure your routers ...
* 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
The changed field can also be fiddled with, i.e if the date is in the future.
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.
Yup, there are many fields were the software 'fiddles' with users data. My opinion is not to make it worse when the benefits are not entirely obvious. David K. ---
participants (2)
-
davidk＠isi.edu -
John LeRoy Crain