Last Wednesday, we had a meeting where we went over technical proposals
for dynamic trust router protocols.  Mark kindly took notes on a
proposal that I made and we all revised for the format of data exchanged
between trust routers.
I'd like to describe the properties of that proposal I think it is
important to maintain in the final protocol.

First, there are two layers of handling each information item.  There is
a large part of the system that doesn't care what type of information is
being carried and a smaller part of the system that does care about the
type of information.

In the type-independent layer we have:

* Keeping track of the Providence tree of sources of the
  information--all the speakers we believe speak for the information and
  what we believe our paths are to the speakers.  We agreed that the
  actual protocol we're developing doesn't need anything other than the
  shortest path, but that debugging and analysis for fraud/misuse will
  significantly benefit from the entire subgraph.

* Look up of all information for a given target_realm and community
  doesn't require knowing about the type of information.

* Look up of a specific information type for a given target_realm and
  community doesn't require understanding the type of information.

* For a number of information types we want to choose the information
  for a given target_realm and community that is closest to us.  For
  the other information types we were aware of, this was neutral or
  positive.  So it seems that we can have the lookup be entirely
  independent of information type.

* We can do a lot of the filtering independent of information type;
  community, target realm, speaker/source/providence/whatever you want
  to call it/type can all be done without knowing about the details of
  the information type.
* Loop detection can of course be done in a type-independent manner.


Then in the layer that is aware of information type we can have:

* Validation rules.  We will need to decide whether to flood information
  types we don't support, but when we do support an information type we
  can do validation on required fields etc.

* We can have type-specific filters when we know about a type

* Type specific logic to configure our local "static routes" and to
  introduce what gets flooded.

* Type specific code to do things like use tids links to understand
  where to forward TID requests.

In my mind the major advantage of this separation is extensibility.  It
will be relatively easy to add new information types provided that the
lookup is based on target_realm and community, and that nearest speaker
is the strategy we want to use for which information to select.
I agree that requires a bit more work to confirm but I've been thinking
about this for several years now and have been able to fit everything
I've considered into that approach well.
If something doesn't fit into type/target_realm/community, then perhaps
the dynamic trust router is the wrong place for it.


I'd appreciate any thoughts on these items.