As a container users, I want to be able to specify my own custom driver so that I can implement my specific network use case.

The plugin themselves would need to adhere to an interface of commands.  We would provide a sample.  These interfaced methods would be:

• setup – sets up a new instance of the network
• See the types here: 
• JSON input via STDIN, fields:
• contianer_id: String
• container_name: String
• port_mappings: Array of PortMapping
• network: Network
• network_options: PerNetworkOptions

• JSON output of StatusBlock on STDOUT, on errors the plugin should return a Error JSON structure see below.

• teardown – used to bring down the previous network setup
• Same input as setup command
• No output on STDOUT, on errors the plugin should return a Error JSON structure see below.

• create – generates a network configuration file
• Gets the Network struct as JSON on STDIN
• Returns the Network struct as JSON on STDOUT
• On errors the plugin should return a Error JSON structure see below.
• Podman will populate the network name and ID before calling netavark. The name and ID cannot be changed by the plugin. The driver name must also not be changed. All other config fields can be changed in the plugin.
• Podman will also populate the fields such as subnet or option when they were set by users, i.e podman network create –subnet. The plugin should validate the input and error if it is not valid.

• info - show info about the plugin
• Output a JSON response on STDOUT with the following fields
• version - String, the plugins version, can be any string.
• api_version - String, semver version of the API between podman/netavark and the plugins. This could allow us to introduce breaking changes in a backwards compatible way if needed. For now set it to “1.0.0”
• Extra fields can be added by the plugin other, podman/netavark should ignore them.

Example: 

Error JSON format:

• `{“error”: ”message”}`. The message can be anything and will be returned to the caller as an error.