This commit consists of:
1) Dockerizing the netconf server
2) Update proto2yang to support module imports
3) Provide a set of yang modules derived from the proto files in voltha.
   These files as well as the slight mmodifications to the proto files are
   provided in the experiments/netconf/proto2yang directory
4) Code to automatically pull proto files from voltha into the netconf server,
   compiles them and produce the yang equivalent files.
5) Add a getvoltha netconf API to provide voltha state information (basic at
   this time).  There is potential to make this generic once we experiment
   with additional APIs

Change-Id: I94f3a1f871b8025ad675d5f9b9b626d1be8b8d36
diff --git a/experiments/netconf/proto2yang/ietf-any.yang b/experiments/netconf/proto2yang/ietf-any.yang
new file mode 100644
index 0000000..bf318af
--- /dev/null
+++ b/experiments/netconf/proto2yang/ietf-any.yang
@@ -0,0 +1,127 @@
+
+module ietf-any {
+
+
+    namespace "urn:opencord:params:xml:ns:voltha:ietf-any";
+    prefix any;
+
+
+    organization "CORD";
+    contact
+        " Any name";
+
+    description
+        "";
+
+    revision "2016-11-15" {
+        description "Initial revision.";
+        reference "reference";
+    }
+
+
+    grouping Any {
+        description
+            "`Any` contains an arbitrary serialized protocol buffer message along with a
+ URL that describes the type of the serialized message.
+
+ Protobuf library provides support to pack unpack Any values in the form
+ of utility functions or additional generated methods of the Any type.
+
+ Example 1: Pack and unpack a message in C++.
+
+     Foo foo = ...;
+     Any any;
+     any.PackFrom(foo);
+     ...
+     if (any.UnpackTo(&foo))  
+       ...
+      
+
+ Example 2: Pack and unpack a message in Java.
+
+     Foo foo = ...;
+     Any any = Any.pack(foo);
+     ...
+     if (any.is(Foo.class))  
+       foo = any.unpack(Foo.class);
+      
+
+  Example 3: Pack and unpack a message in Python.
+
+     foo = Foo(...)
+     any = Any()
+     any.Pack(foo)
+     ...
+     if any.Is(Foo.DESCRIPTOR):
+       any.Unpack(foo)
+       ...
+
+ The pack methods provided by protobuf library will by default use
+ 'type.googleapis.com full.type.name' as the type URL and the unpack
+ methods only use the fully qualified type name after the last ' '
+ in the type URL, for example  foo.bar.com x y.z  will yield type
+ name  y.z .
+
+
+ JSON
+ ====
+ The JSON representation of an `Any` value uses the regular
+ representation of the deserialized, embedded message, with an
+ additional field `@type` which contains the type URL. Example:
+
+     package google.profile;
+     message Person  
+       string first_name = 1;
+       string last_name = 2;
+      
+
+      
+        @type :  type.googleapis.com google.profile.Person ,
+        firstName : <string>,
+        lastName : <string>
+      
+
+ If the embedded message type is well-known and has a custom JSON
+ representation, that representation will be embedded adding a field
+ `value` which holds the custom JSON in addition to the `@type`
+ field. Example (for message  google.protobuf.Duration   ):
+
+      
+        @type :  type.googleapis.com google.protobuf.Duration ,
+        value :  1.212s 
+      ";
+        leaf type_url {
+            type  string; 
+            description
+                "A URL resource name whose content describes the type of the
+ serialized protocol buffer message.
+
+ For URLs which use the scheme `http`, `https`, or no scheme, the
+ following restrictions and interpretations apply:
+
+   If no scheme is provided, `https` is assumed.
+   The last segment of the URL's path must represent the fully
+   qualified name of the type (as in `path google.protobuf.Duration`).
+   The name should be in a canonical form (e.g., leading  .  is
+   not accepted).
+   An HTTP GET on the URL must yield a  google.protobuf.Type   
+   value in binary format, or produce an error.
+   Applications are allowed to cache lookup results based on the
+   URL, or have them precompiled into a binary to avoid any
+   lookup. Therefore, binary compatibility needs to be preserved
+   on changes to types. (Use versioned type names to manage
+   breaking changes.)
+
+ Schemes other than `http`, `https` (or the empty scheme) might be
+ used with implementation specific semantics.";
+        }
+
+        leaf value {
+            type  binary; 
+            description
+                "Must be a valid serialized protocol buffer of the above specified type.";
+        }
+
+    }
+
+}
\ No newline at end of file