URI name space delegation and request-routing

The architecture draft talks about URI name space
delegation. It appears in several places, for instance,
p9, "1. The ORIGIN delegates its URI name space
for objects to be distributed and delivered by the
peering CNs to the REQUEST-ROUTING INTERNETWORKING SYSTEM."
and in p8, "2. PUBLISHERs delegates authority of
their object URI name space being distributed by peering
CNs to the REQUEST-ROUTING INTERNETWORKING SYSTEM." (RRIS)

I find such discussion rather vogue and source
for future trouble. Partly because it is overloading
the URI name space which is basically file-organization
convention most probably meaningful only to the
content publisher. That is to say is it full delegation
of the name space or partial in accordance with business
requirements. Also, delegation to whom? to the RRIS?
Who owns RRIS? and how does CDI accounting play into
the RRIS decisions? request-routing quota!
Should not the delegation be to something identifiable?
and what are these common convention for encoding
metadata into the URI name space?

This problem does not exist in the current CN deployment
cause there is only one authoritative request-routing
system.

Then you move away from this into feedback advertisements
which raises more questions about scalability and performance.
p12, "The AUTHORITATIVE REQUEST-ROUTING SYSTEM subsequently splices
each peering Content Network REQUEST-ROUTING SYSTEM into this
URI name space and transitively delegates URI name space
authority to them for their participation in request-routing."
Then adds in p14 " The REQUEST-ROUTING INTERNETWORKING is
hierarchical in nature. There exists exactly one request-routing
for each publisher URI."

This could have been true if this is a DNS system but it
hardly is. If you look how the DNS operate, it relies upon
iterative resolution although it is hierarchical in nature.
That is why I doubt if the recursive approach in Figure 3
would be practical at all.

I propose moving away from all of this into something
much simpler and most probably interoperable with
the existing CN technologies as described in the
known mechanisms draft. The publisher CIG, primary,
maps request-routing messages into some CN according
to a number of metrics. Once it is forwarded the CN-CIG,
secondary, decides which surrogate(s) would serve the request.
no URI request routing tree. Currently in the context
of CN, there is only one CN mapping, the question becomes
how to add more to that. Feedback advertisement can play
a role here by conveying the CN state to the primary CIG.

The participating CNs that the publisher has contracted
can organize themselves in any standard why they see fit.
The CN-CIGs realizing the distribution can be organized
in a hierarchical, distributive, adaptive etc... manner
where content can be disseminated accordingly. And when
the content is not available within the CN boundaries,
either the origin server or a peer CN is contacted
using known CN distribution protocol(s). The distribution
becomes here a matter of optimization.

I believe that this approach is more modular than
what is being described in the architecture draft.
It also allows for the opportunity of developing
each part independently of the other ones.

my 2 cents,

regards
Abdallah