<div dir="ltr"><div dir="ltr">Hi Michael<br></div><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think what is needed to move on is an open testnet. The policies for the NDN testbed might be suitable for universities, but are unfit for almost everybody else. Big issues that arise with an open testnet are governance, how to structure the global namespace, naming conventions and how to enable a variety of trade-offs (i.e. privacy vs. efficiency).<br></blockquote><div><br></div><div>There was a comment at the 2018 NDN Community Meeting, from an industry person: the NDN testbed is an "empty net", a network that has no meaningful traffic.</div><div>Sadly, this comment still applies today.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="https://named-data.net/ndn-testbed/policies-connecting-nodes-ndn-testbed/">https://named-data.net/ndn-testbed/policies-connecting-nodes-ndn-testbed/</a></div><div class="gmail_quote">As I understand, one of the "unfit" policies is that every NDN testbed node must be controlled by "the NDN testbed management institution".</div><div>The reason is that the current testbed is technically an intra-domain network. In IP terms, it's a single Autonomous System (AS). Naturally, a single entity should be managing this network.</div><div>To have an "open testnet" without centralized control, we would need an inter-domain network.</div><div><br></div><div>What we already have:</div><div><ul><li>High speed forwarding.<br></li><li>Inter-domain hyperbolic routing.</li></ul><div>What are still unresolved:</div></div><div><ul><li>Name assignment policy, as you already mentioned. One of the ideas is to <a href="https://cs.gmu.edu/~eoster/doc/ndnssec.pdf">derive NDN names from DNSSEC</a>, but this would create a dependency on IP infrastructure.<br></li><li>Producer mobility. On the current testbed, producer mobility is supported through prefix readvertisement. When a mobile producer connects to any of the testbed nodes, its prefix is announced into the global routing system. This would not scale in an inter-domain network. The solution is forwarding hint, but it's neither fully specified nor adopted by applications.<br></li><li>Trust of routing messages. Although we have hyperbolic routing, the trust schema in the routing protocol still depends on a single trust anchor, which does not work in an inter-domain network.</li></ul></div><div><br></div><div>I wonder what other policies are deemed "unfit for everybody else"?<br></div><div><br></div><div class="gmail_quote"><div>Yours, Junxiao</div><div><br></div></div></div>