NRTM proposal

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 at nethead.De
Gummersbacherstr. 27            Phone: +49 221 8809210
50679 Cologne, Germany          Fax  : +49 221 8809212