Hi, "Lu, Ping" wrote:

...

If receiving a stream with objects considered "non-standard", or private, all the nrtm client (or the server) has to do is to filter out objects (and maybe attributes) which are considered of private nature. The client doesnt need to know anything about which serial number relates to which object. (i.e. The serial-numbers must not be in sync between a source server and the mirror)

If you don't care whether the serial-numbers match or not then how can you tell the mirrored data is up-to-date ?

if the highest serial-number on both sides is identical, mirror and client are up-to-date.

...

This can easily be accomplished by creating a perl script which filters the NRTM ascii stream.

Actually we are using such a script for synchronizing our local ip-management ripe-database with the RIPE amsterdam.

Could you therefore please elaborate on where you are seeing a problem with the serial-numbers while mirroring?

As I said before if the client can do whatever they want without maintaining

the correct serial-numbers then how can you tell the data is up-to-date ?

All the client has to do is to remember the last processed serial-number. When connecting the next time for syncing he asks for all new objects with a serial-number greater than the last one which he did process (if any). The server than starts sending all objects within this range. Remark: Andrei, can you please correct me in case i am wrong here..?! best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av@nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Cologne, Germany Fax : +49 221 8809212