Regarding Forrest Guides:
We're running into a contradiction here, e.g.:
| For scalability and reliability, there will need to be a
| large number of forest guides, all providing the same
information. A
| seeker can contact any forest guide and will then be directed
to the
| right tree or, rarely, set of trees.
vs.
| Trees can also restrict
| their cooperation to parts of the information. For example, if
| country C does not recognize country T, C can propagate tree
regions
| for all but T.
Either the FGs offer all the same information or they don't.
As I see the problem, we have basically two choices:
One choice is to keep the forrest guides in sync with each other,
with
an automated protocol between them. This is the first statement from
above plus these three sentences:
| A tree node at the top of a tree can contact any forest
| guide and inject new coverage region information into the system.
| One would expect that each tree announces its coverage to more
than
| one forest guide. Each forest guide peers with one or more other
| guides and distributes new coverage region announcements to all
other
| guides.
In that case, this set of forrest guides act just as another layer in
the hierarchical resolution model. Thus we don't actually have a
forrest,
but a single tree with the cluster of forrest guides as the root.
This, of course, reopens the pandora's box of who controls what to put
in there, which was the reason for the introduction of the forrest in
the first place.
Reading between the lines of the security section: Do you propose that
the forrest guides just sync a set of digitally signed tree referrals
amongst each other and then each FG decides based on local
configuration
which ones he considers when answering questions? And who is going to
decide who can participate in this FG coverage exchange system?
The other option is to leave the question of forrest guide
synchronization
completely out of scope and thus don't even try to solve a
political problem
with technical means.
I have this nagging feeling what we want to have our cake and eat
it, too.
/ol
--
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit