Two points of clarification:
1) EIDs need to be aggregatable only if they are used as look up keys.
If they are never the key for a lookup (and some proposals have that
property) then aggregatability is a non-issue.
2) The corollary to 1 is that EIDs only need to be aggregatable in the
structure in which they are looked up. If they are looked up in the
routing system, then they need to be topological. If they are looked up
in something else, then they need to right structure for that something
else. If the EID is a DNS name, then the DNS structure defines its
aggregatability. If it is looked up in a binary delegation tree, then
that defines the structure. If they are looked up in a DHT, and we are
prepared to mandate a DHT, then again they don't need aggregation
properties.
2') It is very likely that EIDs will have at least delegation oriented
aggregation, unless we resort to random EID creation.
Yours,
Joel M. Halpern
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
