Towards a better distributed database model..

bonito at nis.garr.it (bonito at nis.garr.it) on July 14:
> > 
> > 
> > Hi,
> > 
> > Here is a draft David and I put together. Comments/suggestios are
> > welcome.
> > 
> > Thanks.
> > 
> > Cengiz
> 
> Just a comment:
> 
>  It is quite interesting to note how the distribution model you propose
>  (non-hierarchical peering, neighbor registries, ...) resembles BGP ;-)

This is what happens when routing people design distribution models:-)

> 
> a remark:
> 
>  assuming the "no source attribute" solution is chosen, which I see
>  as the best, I understand from your phrasing:
> 
>  > [...]     Each maintainer object specifies a registry which
>  > is authoritative for the objects that are maintained by itself.
>  > 
>  > When a user sends an update to a registry, that registry will forward it
>  > to the registry which is authoritative for the object. The authoritative
>  > registry updates its local copy of the database and invokes the flooding
>  > protocol for other registries to pick up this change.
>  > 
>  > Note that, if an object is registered in the database with maintainer X
>  > who authorizes registry Y, all updates will be performed by registry
>  > Y. This will ensure consistency within Y's copy of the database. If
>  > someone tries to register the same object with a different maintainer than
>  > X, Y (or any other registry) will deny the update with a maintainer
>  > failure error.
> 
>  that the authoritative registry for a certain object is in practice
>  the registry where the object's maintainer is registered. I think it
>  should be expressed more clearly. Something like:
>    [...]
>    When a user sends an update to a registry, that registry will
>    forward it to the registry which is authoritative for the object
>    (i.e. the registry specified in the object's maintainer entry).
>    [...]

Thanks. We will change the draft as you suggested.

> 
> and a proposal:
> 
>  since the objects returned upon request by certain registry are
>  actually data received by neighbor registries through some "distribution
>  path" why not recycling the source attribute (or invent a new one) to
>  keep track of that path? I'm prettu sure that this information may
>  prove useful.

Good point. We have not nailed down the details yet. Another attribute
which we are thinking of is time stamps to show at what time the update
was processed.

> 
> ----------                                                     ----------
> Antonio_Blasco Bonito                          E-Mail: bonito at nis.garr.it
> GARR - Network Information Service      c=it;a=garr;p=garr;o=nis;s=bonito
> c/o CNUCE - Istituto del CNR                         Tel: +39 (50) 593246
> Via S. Maria, 36                                    Telex: 500371 CNUCE I
> 56126 PISA   Italy                                   Fax: +39 (50) 904052
> ----------                                                     ----------


Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California
http://www.isi.edu/div7/people/cengiz.home