Comment 4 for bug 1521291

Thanks for moving this forward, Richard.

Supporting neutron API by openstackclient does not mean the deprecation of neutronclient directly.

In addition to the basic transition step, I think the following thing needs to be covered:

* subcommand naming conventions (openstackclient approach easily causes subcommand naming conflict. we need a guideline. do we need some reserved prefix or something?)
* option convention: the current neutronclient supports various types of parameters. we need to assess the current openstackclient convention supports all or we need to expand the convention.
  I recently proposed a patch to neutronclient which tries to describe neutronclient command line option conventions. I don't want to see this kind of discussions in openstackclient implementation. we would like to check osc conventions first.
* what's the future of extra args of neutronclient? Honestly speaking, I don't like it because it is a chaos area and brings a lot of confusions. It is sometimes useful for extensibility but it is too flexible....

I will check the contents you captured in the etherpad page.