bonito@nis.garr.it (bonito@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@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