<div class="gmail_quote"><div dir="ltr">On Tue, Jan 31, 2017, 12:46 PM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br></div><div class="gmail_msg">I propose dropping implicit face creation feature during nfdc refactoring:</div><div class="gmail_msg">(1) <font face="monospace, monospace" class="gmail_msg">nfdc face create</font> is the only subcommand that can create a face.</div><div class="gmail_msg">(2) <font face="monospace, monospace" class="gmail_msg">nfdc route add</font> and <font face="monospace, monospace" class="gmail_msg">nfdc route remove</font> (replacements of <font face="monospace, monospace" class="gmail_msg">nfdc register</font> and <font face="monospace, monospace" class="gmail_msg">nfdc unregister</font>) 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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This is consistent with iproute2 programs, where you must explicitly create an interface before using it in IP routing tables.</div><div class="gmail_msg"></div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"></div></div></blockquote></div><div><br></div><div>I support this proposal.</div><div><br></div><div>Thanks,</div><div>Davide </div>