[Nfd-dev] [Ndn-app] NFD faces/create: requires canonical FaceUri

[Burke, Jeff]

Hi Jeff

DNS resolution is simply not the responsibility of NFD. Management utility (nfdc) should take care of that.

Hi Junxiao,

I'm not arguing with the separation, but I want to understand the design rationale so that I can better understand what goes in and what stays out of NFD from the perspective of those developing it.    What is it about DNS resolution that motivated its exclusion from NFD?

Thanks,
Jeff

After completing the resolution process, a canonical FaceUri is generated and passed to NFD for face creation (and face query).

I'm not assuming anything about how NFD is used in the community.
The first message in this thread is an announcement that all users must change their programs if they are using this specific feature.


Face query operation requires exact match of FaceUri. That's why NFD expects a canonical FaceUri that remains the same for the same endpoint. Allowing any alias of a canonical FaceUri would cause problems in face query operation.

The usage of udp4, udp6, tcp4, tcp6 doesn't require IANA registration, because FaceUri is not in the same namespace as URI.

Yours, Junxiao

On Mon, Dec 1, 2014 at 9:00 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Hi Junxiao,

Hi Jeff

DNS is a complex affair that has many details to take care of.

I don't understand exactly what's complex for NFD here;  is it the asynchronous nature of the resolution process that you prefer not be handled in the daemon?

NFD isn't the right place to perform DNS resolution, so we have decided to off-load this operation to the client library.
ndn-cxx provides FaceUri::isCanonical method that determines whether a FaceUri is canonical.
ndn-cxx provides FaceUri::canonize method to perform DNS resolution, and obtain a canonical FaceUri.

Most users shouldn't be affected, because nfdc command line tool will canonize FaceUri before creating face.

NLSR is the only known app that uses faces/create command through ndn-cxx Controller API, and NLSR has been updated

I'm not sure that it's good practice to assume you know the cases in which the library and daemon are being used in the research community.

Apps based on ndn-ccl shouldn't be affected because ndn-ccl API doesn't have a face creation method.

udp and udp4 are not equivalent. udp can be resolved to either udp4 or udp6.
udp://192.0.2.1<http://192.0.2.1> will be canonized as udp4://192.0.2.1:6363<http://192.0.2.1:6363>

Yes, all I was getting at is that the convention could be similarly defined at the NFD level.

Is the use of udp and tcp in URI schemes, rather than, say, ndnudp or ndntcp going to cause any conflicts with registered URI schemes in  the future? http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20141201/6b92af4a/attachment.html>