NFD

2017-10-09 call decided to extend nfdc route add to support implicit creation of faces. To support face flags, nfdc route add should support the same optional flags as nfdc face create and in future we need to make sure that optional flags are non-overlapping.

I found the discussion: http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2017-January/002223.html

Did the conference call consider the arguments given in note-6? If not, this matter should be re-discussed.

there should probably be an option to prevent the automatic creation of the face

Not creating a face should be the default. Creating a face may be behind an argument allow-face-creation. All face creation arguments need to be named and not positional.

Davide Pesavento wrote:

I found the discussion: http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2017-January/002223.html

Now I remember the conversation and my position regarding this issue was the same. I was told (may be I misunderstood, though) that the behavior with implicit face creation would not change for "register" stage. Therefore, I agreed in the end. However, that agreement was under the understanding that users are not introduced a new burden to run two commands or "remember" to type additional command line options.

Junxiao Shi wrote:

Not creating a face should be the default. Creating a face may be behind an argument allow-face-creation. All face creation arguments need to be named and not positional.

I disagree with this. My proposal is exactly the opposite. The default: implicit creation of the face (for nfd route add only). The flag disable-face-create to disable implicit face creation capability when FaceUri is specified. There is no implicit creation when face Id is specified.

What's the status of this issue?

Here is my personal experience on this:
I tried the new commands to connect two NFDs. Specifically, I used the first command nfdc face create udp4://192.168.2.3:6363 to create a face (FaceId = 263), then I used nfdc route add /test 263 to add a route. Note that I tried several times and figured out to use the FaceId when creating a route. Compared to the previous command and tutorial, the new commands are less user-friendly. As a user, I would prefer the deprecated command.

I used the first command nfdc face create udp4://192.168.2.3:6363 to create a face (FaceId = 263), then I used nfdc route add /test 263 to add a route.

The second command could also be nfdc route add /test udp4://192.168.2.3:6363, if that remote FaceUri is unique. It’s just that the first command becomes mandatory.

I want to upvote this bugreport.

What should the behavior be if the face already exists but face options are specified to route add? Should the options be ignored or should the face be updated to use the new options?

Eric Newberry wrote:

What should the behavior be if the face already exists but face options are specified to route add? Should the options be ignored or should the face be updated to use the new options?

What options? nfdc route add doesn't support any face options as far as I know.

Davide Pesavento wrote:

Eric Newberry wrote:

What should the behavior be if the face already exists but face options are specified to route add? Should the options be ignored or should the face be updated to use the new options?

What options? nfdc route add doesn't support any face options as far as I know.

See note 5 above.

Alex Afanasyev wrote:

To support face flags, nfdc route add should support the same optional flags as nfdc face create and in future we need to make sure that optional flags are non-overlapping.

Oh, I would actually be slightly against that. It could become quite messy to support (and document!) all face settings in both places. Moreover, a "face-creating" route add is supposed to be a shortcut, in my opinion it doesn't have to support all possible face flags and options, just the local/remote FaceUris (and maybe persistency) should be enough to cover the vast majority of use cases. More advanced settings can still be changed using the face create + route add combination.

Eventually we should introduce a nfdc face set (exact name TBD) that allows changing the parameters of an existing face, essentially equivalent to the "update" part of face create, except that it fails if the face doesn't already exist. This can already be done with face create today, but "create" here is completely counterintuitive when the user knows that the face already exists. In fact, I'm starting to think that giving also "update" semantics to face create was a mistake.