Hi Xiaohu,
|1) Burden the control policy configuration. | |Since the flat identifier has no hierarchy, it's hard to |enforce identifier-block based security control policy on |firewalls. That's to say, only host granularity access control |list is available. True, but even with aggregatability, you still have an issue. What happens when the aggregation mechanism doesn't match your desired identifier block? Not everyone is clever enough to allocate addresses to match their security policies and the results are predictable: really long ACLs. In fact, what you're asking for is another semantic overload: easy grouping of identifiers for instantiating security policy. Isn't that the same type of problem that got us here in the first place, with a semantic overload between transport and routing? Perhaps security should be set based. |2) Lack of trust and economic model in the id/locator mapping system. | |Since these flat identifiers are randomly scattered across the |namespace and stored at essentially random nodes, the |id/locator resolution infrastructure has no "pay-for-your-own" |model, unless the id/locator resolution infrastructure is |managed by one and only one authority. | |So I wonder whether the flat identifier is acceptable for the |id/locator split architecture. Again, not all proposals seem to require an id to locator mapping. If none is needed, then there is no need to pay for it. Tony -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
