[Nfd-dev] nfdc implicit face creation problems

[Davide Pesavento]

On Tue, Jan 31, 2017 at 12:59 PM, Alex Afanasyev <aa at cs.ucla.edu> wrote:
>
> On Jan 31, 2017, at 9:53 AM, Davide Pesavento <davide.pesavento at lip6.fr>
> wrote:
>
> On Tue, Jan 31, 2017, 12:46 PM Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>>
>>
>> I propose dropping implicit face creation feature during nfdc refactoring:
>> (1) nfdc face create is the only subcommand that can create a face.
>> (2) nfdc route add and nfdc route remove (replacements of nfdc register
>> and nfdc unregister) do not implicitly create faces. They can accept either
>> FaceId or FaceUri. When specifying FaceUri, we query the existing faces
>> whose RemoteUri matches the specified FaceUri. If one exact match is found,
>> that face is used. If no face with that RemoteUri is found, an error message
>> is printed. If two or more matches are found, an error message is printed
>> with the list of matched faces, and the operator can re-run the command with
>> one of the FaceIds from that list.
>>
>> This is consistent with iproute2 programs, where you must explicitly
>> create an interface before using it in IP routing tables.
>
>
> I support this proposal.
>
>
> 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.
>

Junxiao listed 4 problems with the current approach. Consistency with
iproute2 is not one of them. It would be an additional bonus (assuming
we consider interface == face, which is arguable), but it's definitely
not the main reason behind this proposal.

Can you elaborate on the "inter-command dependency"? I'm not sure what
you mean and how it is a problem.

Thanks,
Davide