[Nfd-dev] nfdc implicit face creation problems

Junxiao Shi shijunxiao at email.arizona.EDU
Tue Jan 31 10:18:48 PST 2017


Dear folks

I do not support this proposal.  This creates inter-commmand dependency for
> basic operations as registering prefix to a new face.  We should not create
> more obstacles for users for the sake of having consistent interface with
> IP tools.
>

Let's rewarm the original rationale of introducing *implicit face creation*:
what we needed is not implicit face creation, but the ability to write
FaceUri into nfdc register command in place of FaceId.
Before #1515, nfdc register command only accepts FaceId. A caller must
first invoke nfdc create, scrape its output (or nfd-status -f output), and
then invoke nfdc register. This is the "inter-command dependency".

At that time, there were no faces/query operation, so that the easiest way
to obtain FaceId from FaceUri is to execute faces/create command. It has
caused a long list of concerns in #1515
<https://redmine.named-data.net/issues/1515>.
When faces/query operation was later introduced, some of the concerns are
solved, but it's too late the change the semantics of nfdc register
subcommand.

Under the new proposal, nfdc route add command accepts FaceUri and uses
that to query an existing face. This should not be considered
"inter-command dependency", because the operator can simply run "nfdc face
create udp://hobo.cs.arizona.edu && nfdc route add / udp://
hobo.cs.arizona.edu" without scraping the output of the first subcommand.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170131/f02c85fd/attachment.html>


More information about the Nfd-dev mailing list