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

[Burke, Jeff]

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

Yours, Junxiao

On Nov 28, 2014 12:45 PM, "Burke, Jeff" <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi Junxiao,

Thanks.  What's the design rationale for the changes?   (In general, I'd suggest that API updates should include at least a brief statement on why they're being made.)

The removal of support for DNS names seems odd from a usability standpoint, and I don't understand why udp and udp4 can't just be considered equivalent.

Thanks,
Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Thu, 27 Nov 2014 20:59:27 -0700
To: "ndn-app at lists.cs.ucla.edu<mailto:ndn-app at lists.cs.ucla.edu>" <ndn-app at lists.cs.ucla.edu<mailto:ndn-app at lists.cs.ucla.edu>>, "ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>" <ndn-lib at lists.cs.ucla.edu<mailto:ndn-lib at lists.cs.ucla.edu>>, "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: [Ndn-app] NFD faces/create: requires canonical FaceUri

Dear folks

Please be aware of an upcoming NFD Management API change: faces/create command requires canonical FaceUri.
This change will happen no sooner than Dec 04 12:00 UTC.

A canonical FaceUri for UDP and TCP tunnels should specify either IPv4 or IPv6, have IP address instead of hostname, and contain port number.

Examples of canonical FaceUri:
udp4://192.0.2.1:6363<http://192.0.2.1:6363>
udp6://[2001:db8::1]:6363
tcp4://192.0.2.1:6363<http://192.0.2.1:6363>
tcp6://[2001:db8::1]:6363

Examples of non-canonical FaceUri that will be rejected by faces/create command after the change:
udp://192.0.2.1<http://192.0.2.1>
udp://example.net:6363<http://example.net:6363>
udp4://example.net:6363<http://example.net:6363>
udp6://example.net:6363<http://example.net:6363>
tcp://192.0.2.1<http://192.0.2.1>
tcp://example.net:6363<http://example.net:6363>
tcp4://example.net:6363<http://example.net:6363>
tcp6://example.net:6363<http://example.net:6363>

If you have a library / application that utilizes NFD faces/create command, please canonize the FaceUri before sending the command.
Scripts calling nfdc command line tool are unaffected by this change.

Yours, Junxiao
_______________________________________________ Ndn-app mailing list Ndn-app at lists.cs.ucla.edu<mailto:Ndn-app at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20141201/c737fbf5/attachment.html>