5.  IANA Considerations

   This document registers two URIs in the "IETF XML Registry"
   [RFC3688].  Following the format in RFC 3688, the following
   registrations have been made.

        URI: urn:ietf:params:xml:ns:yang:ietf-snmp
        Registrant Contact: The NETMOD WG of the IETF.
        XML: N/A, the requested URI is an XML namespace.

        URI: urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name
        Registrant Contact: The NETMOD WG of the IETF.
        XML: N/A, the requested URI is an XML namespace.

   This document registers the following YANG modules in the "YANG
   Module Names" registry [RFC6020].

        name:         ietf-snmp
        namespace:    urn:ietf:params:xml:ns:yang:ietf-snmp
        prefix:       snmp
        reference:    RFC 7407

        name:         ietf-x509-cert-to-name
        namespace:    urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name
        prefix:       x509c2n
        reference:    RFC 7407
   The document registers the following YANG submodules in the "YANG
   Module Names" registry [RFC6020].

        name:         ietf-snmp-common
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-engine
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-community
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-notification
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-target
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-vacm
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-usm
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-tsm
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-tls
        parent:       ietf-snmp
        reference:    RFC 7407

        name:         ietf-snmp-ssh
        parent:       ietf-snmp
        reference:    RFC 7407

6.  Security Considerations

   The YANG module and submodules defined in this memo are designed to
   be accessed via the NETCONF protocol [RFC6241].  The lowest NETCONF
   layer is the secure transport layer and the mandatory to implement
   secure transport is SSH [RFC6242].  The NETCONF access control model
   [RFC6536] provides the means to restrict access for particular
   NETCONF users to a pre-configured subset of all available NETCONF
   protocol operations and content.

   There are a number of data nodes defined in the YANG module and
   submodules which are writable/creatable/deletable (i.e., config true,
   which is the default).  These data nodes may be considered sensitive
   or vulnerable in some network environments.  Write operations (e.g.,

   edit-config) to these data nodes without proper protection can have a
   negative effect on network operations.  These are the subtrees and
   data nodes and their sensitivity/vulnerability:

   o  The "/snmp/engine" subtree contains the configuration of general
      parameters of an SNMP engine such as the endpoints to listen on,
      the transports and SNMP versions enabled, or the engine's
      identity.  Write access to this subtree should only be granted to
      entities configuring general SNMP engine parameters.

   o  The "/snmp/target" subtree contains the configuration of SNMP
      targets and, in particular, which transports to use and their
      security parameters.  Write access to this subtree should only be
      granted to the security administrator and entities configuring
      SNMP notification forwarding behavior.

   o  The "/snmp/notify" and "/snmp/notify-filter-profile" subtrees
      contain the configuration for the SNMP notification forwarding and
      filtering mechanism.  Write access to these subtrees should only
      be granted to entities configuring SNMP notification forwarding
      behavior.

   o  The "/snmp/proxy" subtree contains the configuration for SNMP
      proxies.  Write access to this subtree should only be granted to
      entities configuring SNMP proxies.

   o  The "/snmp/community" subtree contains the configuration of the
      Community-based Security Model.  Write access to this subtree
      should only be granted to the security administrator.

   o  The "/snmp/usm" subtree contains the configuration of the User-
      based Security Model.  Write access to this subtree should only be
      granted to the security administrator.

   o  The "/snmp/tsm" subtree contains the configuration of the
      Transport Layer Security (TLS) Transport Model for SNMP.  Write
      access to this subtree should only be granted to the security
      administrator.

   o  The "/snmp/tlstm" subtree contains the configuration of the SNMP
      transport over (D)TLS and, in particular, the configuration of how
      certificates are mapped to SNMP security names.  Write access to
      this subtree should only be granted to the security administrator.

   o  The "/snmp/vacm" subtree contains the configuration of the View-
      based Access Control Model used by SNMP to authorize access to
      management information via SNMP.  Write access to this subtree
      should only be granted to the security administrator.

   Some of the readable data nodes in the YANG module and submodules may
   be considered sensitive or vulnerable in some network environments.
   It is thus important to control read access (e.g., via get, get-
   config, or notification) to these data nodes.  These are the subtrees
   and data nodes and their sensitivity/vulnerability:

   o  The "/snmp/engine" subtree exposes general information about an
      SNMP engine such as which version(s) of SNMP are enabled or which
      transports are enabled.

   o  The "/snmp/target" subtree exposes information about which
      transports are used to reach certain SNMP targets and which
      transport-specific parameters are used.

   o  The "/snmp/notify" and "/snmp/notify-filter-profile" subtrees
      expose information about how notifications are filtered and
      forwarded to notification targets.

   o  The "/snmp/proxy" subtree exposes information about proxy
      relationships.

   o  The "/snmp/community", "/snmp/usm", "/snmp/tsm", "/snmp/tlstm",
      and "/snmp/vacm" subtrees are specifically sensitive since they
      expose information about the authentication and authorization
      policy used by an SNMP engine.

   Changes to the SNMP access control rules should be done in an atomic
   way (through a single edit-config or a single commit), or care must
   be taken that they are done in a sequence that does not temporarily
   open access to resources.  Implementations supporting SNMP write
   access must ensure that any SNMP access control rule changes over
   NETCONF are also atomic to the SNMP instrumentation.  In particular,
   changes involving an internal delete/create cycle (e.g., to move a
   user to a different group) must be done with sufficient protections
   such that even a power fail immediately after the delete does not
   leave the administrator locked out.

   Security administrators need to ensure that NETCONF access control
   rules and SNMP access control rules implement a consistent security
   policy.  Specifically, the SNMP access control rules should prevent
   accidental leakage of sensitive security parameters such as community
   strings.  See the Security Considerations section of [RFC3584] for
   further details.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010, <http://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, June 2011,
              <http://www.rfc-editor.org/info/rfc6242>.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536, March
              2012, <http://www.rfc-editor.org/info/rfc6536>.

   [RFC6991]  Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
              July 2013, <http://www.rfc-editor.org/info/rfc6991>.

7.2.  Informative References

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002, <http://www.rfc-editor.org/info/rfc3411>.

   [RFC3412]  Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
              "Message Processing and Dispatching for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3412, December
              2002, <http://www.rfc-editor.org/info/rfc3412>.

   [RFC3413]  Levi, D., Meyer, P., and B. Stewart, "Simple Network
              Management Protocol (SNMP) Applications", STD 62, RFC
              3413, December 2002,
              <http://www.rfc-editor.org/info/rfc3413>.

   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002,
              <http://www.rfc-editor.org/info/rfc3414>.

   [RFC3415]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
              Access Control Model (VACM) for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3415, December
              2002, <http://www.rfc-editor.org/info/rfc3415>.

   [RFC3417]  Presuhn, R., "Transport Mappings for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3417, December
              2002, <http://www.rfc-editor.org/info/rfc3417>.

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62, RFC
              3418, December 2002,
              <http://www.rfc-editor.org/info/rfc3418>.

   [RFC3419]  Daniele, M. and J. Schoenwaelder, "Textual Conventions for
              Transport Addresses", RFC 3419, December 2002,
              <http://www.rfc-editor.org/info/rfc3419>.

   [RFC3584]  Frye, R., Levi, D., Routhier, S., and B. Wijnen,
              "Coexistence between Version 1, Version 2, and Version 3
              of the Internet-standard Network Management Framework",
              BCP 74, RFC 3584, August 2003,
              <http://www.rfc-editor.org/info/rfc3584>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004, <http://www.rfc-editor.org/info/rfc3688>.

   [RFC3826]  Blumenthal, U., Maino, F., and K. McCloghrie, "The
              Advanced Encryption Standard (AES) Cipher Algorithm in the
              SNMP User-based Security Model", RFC 3826, June 2004,
              <http://www.rfc-editor.org/info/rfc3826>.

   [RFC5591]  Harrington, D. and W. Hardaker, "Transport Security Model
              for the Simple Network Management Protocol (SNMP)", STD
              78, RFC 5591, June 2009,
              <http://www.rfc-editor.org/info/rfc5591>.

   [RFC5592]  Harrington, D., Salowey, J., and W. Hardaker, "Secure
              Shell Transport Model for the Simple Network Management
              Protocol (SNMP)", RFC 5592, June 2009,
              <http://www.rfc-editor.org/info/rfc5592>.

   [RFC6353]  Hardaker, W., "Transport Layer Security (TLS) Transport
              Model for the Simple Network Management Protocol (SNMP)",
              STD 78, RFC 6353, July 2011,
              <http://www.rfc-editor.org/info/rfc6353>.

   [RFC6643]  Schoenwaelder, J., "Translation of Structure of Management
              Information Version 2 (SMIv2) MIB Modules to YANG
              Modules", RFC 6643, July 2012,
              <http://www.rfc-editor.org/info/rfc6643>.

Appendix A.  Example Configurations

A.1.  Engine Configuration Example

   Below is an XML instance document showing a configuration of an SNMP
   engine listening on UDP port 161 on IPv4 and IPv6 endpoints and
   accepting SNMPv2c and SNMPv3 messages.

   <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
     <engine>
       <enabled>true</enabled>
       <listen>
         <name>all-ipv4-udp</name>
         <udp>
           <ip>0.0.0.0</ip>
           <port>161</port>
         </udp>
       </listen>
       <listen>
         <name>all-ipv6-udp</name>
         <udp>
           <ip>::</ip>
           <port>161</port>
         </udp>
       </listen>
       <version>
         <v2c/>
         <v3/>
       </version>
       <engine-id>80:00:02:b8:04:61:62:63</engine-id>
     </engine>
   </snmp>

A.2.  Community Configuration Example

   Below is an XML instance document showing a configuration that maps
   the community name "public" to the security-name "community-public"
   on the local engine with the default context name.  The target tag
   "community-public-access" filters the access to this community name.

   <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
     <community>
       <index>1</index>
       <text-name>public</text-name>
       <security-name>community-public</security-name>
       <target-tag>community-public-access</target-tag>
     </community>
     <target>

       <name>management-station</name>
       <udp>
         <ip>2001:db8::abcd</ip>
         <port>161</port>
       </udp>
       <tag>blue</tag>
       <tag>community-public-access</tag>
       <target-params>v2c-public</target-params>
     </target>
     <target-params>
       <name>v2c-public</name>
       <v2c>
         <security-name>community-public</security-name>
       </v2c>
     </target-params>
   </snmp>

A.3.  User-Based Security Model Configuration Example

   Below is an XML instance document showing the configuration of a
   local user "joey" who has no authentication or privacy keys.  For the
   remote SNMP engine identified by the snmpEngineID
   '800002b804616263'H, two users are configured.  The user "matt" has a
   localized SHA authentication key, and the user "russ" has a localized
   SHA authentication key and an AES encryption key.

   <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
     <usm>
       <local>
         <user>
           <name>joey</name>
         </user>
       </local>
       <remote>
         <engine-id>00:00:00:00:00:00:00:00:00:00:00:02</engine-id>
         <user>
           <name>matt</name>
           <auth>
             <sha>
               <!--
                   The 'key' value is split into two lines to conform to
                   the RFC formatting rules.
               -->
               <key>66:95:fe:bc:92:88:e3:62:82:23:
                    5f:c7:15:1f:12:84:97:b3:8f:3f</key>
             </sha>
           </auth>
         </user>

         <user>
           <name>russ</name>
           <auth>
             <sha>
               <!--
                   The 'key' value is split into two lines to conform to
                   the RFC formatting rules.
               -->
               <key>66:95:fe:bc:92:88:e3:62:82:23:
                    5f:c7:15:1f:12:84:97:b3:8f:3f</key>
             </sha>
           </auth>
           <priv>
             <aes>
               <!--
                   The 'key' value is split into two lines to conform to
                   the RFC formatting rules.
               -->
               <key>66:95:fe:bc:92:88:e3:62:82:23:
                    5f:c7:15:1f:12:84</key>
             </aes>
           </priv>
         </user>
       </remote>
     </usm>
     <target>
       <name>bluebox</name>
       <udp>
         <ip>2001:db8::abcd</ip>
         <port>161</port>
       </udp>
       <tag>blue</tag>
       <target-params>matt-auth</target-params>
     </target>
     <target-params>
       <name>matt-auth</name>
       <usm>
         <user-name>matt</user-name>
         <security-level>auth-no-priv</security-level>
       </usm>
     </target-params>
   </snmp>

A.4.  Target and Notification Configuration Example

   Below is an XML instance document showing the configuration of a
   notification generator application (see Appendix A of [RFC3413]).
   Note that the USM-specific objects are defined in the "ietf-snmp-usm"
   submodule.

   <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
     <target>
       <name>addr1</name>
       <udp>
         <ip>192.0.2.3</ip>
         <port>162</port>
       </udp>
       <tag>group1</tag>
       <target-params>joe-auth</target-params>
     </target>
     <target>
       <name>addr2</name>
       <udp>
         <ip>192.0.2.6</ip>
         <port>162</port>
       </udp>
       <tag>group1</tag>
       <target-params>joe-auth</target-params>
     </target>
     <target>
       <name>addr3</name>
       <udp>
         <ip>192.0.2.9</ip>
         <port>162</port>
       </udp>
       <tag>group2</tag>
       <target-params>bob-priv</target-params>
     </target>
     <target-params>
       <name>joe-auth</name>
       <usm>
         <user-name>joe</user-name>
         <security-level>auth-no-priv</security-level>
       </usm>
     </target-params>
     <target-params>
       <name>bob-priv</name>
       <usm>
         <user-name>bob</user-name>
         <security-level>auth-priv</security-level>
       </usm>

     </target-params>
     <notify>
       <name>group1</name>
       <tag>group1</tag>
       <type>trap</type>
     </notify>
     <notify>
       <name>group2</name>
       <tag>group2</tag>
       <type>trap</type>
     </notify>
   </snmp>

A.5.  Proxy Configuration Example

   Below is an XML instance document showing the configuration of a
   proxy forwarder application.  It proxies SNMPv2c messages from
   command generators to a file server running an SNMPv1 agent that
   recognizes two community strings, "private" and "public", with
   different associated read views.  The file server is represented as
   two "target" instances, one for each community string.

   If the proxy receives an SNMPv2c message with the community string
   "public" from a device in the "Office Network" or "Home Office
   Network", it gets tagged as "trusted", and the proxy uses the
   "private" community string when sending the message to the file
   server.  Other SNMPv2c messages with the community string "public"
   get tagged as "non-trusted", and the proxy uses the "public"
   community string for these messages.  There is also a special
   "backdoor" community string that can be used from any location to get
   "trusted" access.

   The "Office Network" and "Home Office Network" are represented as two
   "target" instances.  These "target" instances have target-params
   "none", which refers to a non-existing target-params entry.

   <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
     <target>
       <name>File Server (private)</name>
       <udp>
         <ip>192.0.2.1</ip>
       </udp>
       <target-params>v1-private</target-params>
     </target>
     <target>
       <name>File Server (public)</name>
       <udp>
         <ip>192.0.2.1</ip>

       </udp>
       <target-params>v1-public</target-params>
     </target>
     <target>
       <name>Office Network</name>
       <udp>
         <ip>192.0.2.0</ip>
         <prefix-length>24</prefix-length>
       </udp>
       <tag>office</tag>
       <target-params>none</target-params>
     </target>
     <target>
       <name>Home Office Network</name>
       <udp>
         <ip>203.0.113.0</ip>
         <prefix-length>24</prefix-length>
       </udp>
       <tag>home-office</tag>
       <target-params>none</target-params>
     </target>
     <target-params>
       <name>v1-private</name>
       <v1>
         <security-name>private</security-name>
       </v1>
     </target-params>
     <target-params>
       <name>v1-public</name>
       <v1>
         <security-name>public</security-name>
       </v1>
     </target-params>
     <target-params>
       <name>v2c-public</name>
       <v2c>
         <security-name>public</security-name>
       </v2c>
     </target-params>

     <!--
         Communities c1, c2, c3, and c4 are used for incoming messages
         that should be forwarded.

         Communities c3 and c5 are used for outgoing messages to the
         file server.
     -->
     <community>

       <index>c1</index>
       <security-name>public</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>trusted</context>
       <target-tag>office</target-tag>
     </community>
     <community>
       <index>c2</index>
       <security-name>public</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>trusted</context>
       <target-tag>home-office</target-tag>
     </community>
     <community>
       <index>c3</index>
       <security-name>public</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>not-trusted</context>
     </community>
     <community>
       <index>c4</index>
       <text-name>backdoor</text-name>
       <security-name>public</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>trusted</context>
     </community>
     <community>
       <index>c5</index>
       <security-name>private</security-name>
       <engine-id>80:00:61:81:c8</engine-id>
       <context>trusted</context>
     </community>

     <proxy>
       <name>p1</name>
       <type>read</type>
       <context-engine-id>80:00:61:81:c8</context-engine-id>
       <context-name>trusted</context-name>
       <target-params-in>v2c-public</target-params-in>
       <single-target-out>File Server (private)</single-target-out>
     </proxy>
     <proxy>
       <name>p2</name>
       <type>read</type>
       <context-engine-id>80:00:61:81:c8</context-engine-id>
       <context-name>not-trusted</context-name>
       <target-params-in>v2c-public</target-params-in>
       <single-target-out>File Server (public)</single-target-out>

     </proxy>
   </snmp>

   If an SNMPv2c Get request with community string "public" is received
   from an IP address tagged as "office" or "home-office", or if the
   request is received from anywhere else with community string
   "backdoor", the implied context is "trusted" so proxy entry "p1"
   matches.  The request is forwarded to the file server as SNMPv1 with
   community "private" using community table entry "c5" for outbound
   params lookup.

   If an SNMPv2c Get request with community string "public" is received
   from any other IP address, the implied context is "not-trusted" so
   proxy entry "p2" matches, and the request is forwarded to the file
   server as SNMPv1 with community "public".

A.6.  View-Based Access Control Model Configuration Example

   Below is an XML instance document showing the minimum-secure VACM
   configuration (see Appendix A of [RFC3415]).

   <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
     <vacm>
       <group>
         <name>initial</name>
         <member>
           <security-name>initial</security-name>
           <security-model>usm</security-model>
         </member>
         <access>
           <context></context>
           <security-model>usm</security-model>
           <security-level>no-auth-no-priv</security-level>
           <read-view>restricted</read-view>
           <notify-view>restricted</notify-view>
         </access>
         <access>
           <context></context>
           <security-model>usm</security-model>
           <security-level>auth-no-priv</security-level>
           <read-view>internet</read-view>
           <write-view>internet</write-view>
           <notify-view>internet</notify-view>
         </access>
       </group>
       <view>
         <name>initial</name>
         <include>1.3.6.1</include>

       </view>
       <view>
         <name>restricted</name>
         <include>1.3.6.1</include>
       </view>
     </vacm>
   </snmp>

   The following XML instance document shows the semi-secure VACM
   configuration (only the view configuration is different).

   <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
     <vacm>
       <group>
         <name>initial</name>
         <member>
           <security-name>initial</security-name>
           <security-model>usm</security-model>
         </member>
         <access>
           <context></context>
           <security-model>usm</security-model>
           <security-level>no-auth-no-priv</security-level>
           <read-view>restricted</read-view>
           <notify-view>restricted</notify-view>
         </access>
         <access>
           <context></context>
           <security-model>usm</security-model>
           <security-level>auth-no-priv</security-level>
           <read-view>internet</read-view>
           <write-view>internet</write-view>
           <notify-view>internet</notify-view>
         </access>
       </group>
       <view>
         <name>initial</name>
         <include>1.3.6.1</include>
       </view>
       <view>
         <name>restricted</name>
         <include>1.3.6.1.2.1.1</include>
         <include>1.3.6.1.2.1.11</include>
         <include>1.3.6.1.6.3.10.2.1</include>
         <include>1.3.6.1.6.3.11.2.1</include>
         <include>1.3.6.1.6.3.15.1.1</include>
       </view>
     </vacm>

   </snmp>

A.7.  Transport Layer Security Transport Model Configuration Example

   Below is an XML instance document showing the configuration of the
   mapping of certificate to security name (see Appendices A.2 and A.3
   of [RFC6353]).

   <snmp xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp"
         xmlns:x509c2n=
           "urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name">
     <tlstm>
       <cert-to-name>
         <id>1</id>
         <fingerprint>11:0A:05:11:00</fingerprint>
         <map-type>x509c2n:san-any</map-type>
       </cert-to-name>
       <cert-to-name>
         <id>2</id>
         <fingerprint>11:0A:05:11:00</fingerprint>
         <map-type>x509c2n:specified</map-type>
         <name>
           Joe Cool
         </name>
       </cert-to-name>
     </tlstm>
   </snmp>

Acknowledgments

   The authors want to thank Wes Hardaker and David Spakes for their
   detailed reviews.  Additional valuable comments were provided by
   David Harrington, Borislav Lukovic, and Randy Presuhn.

   Juergen Schoenwaelder was partly funded by Flamingo, a Network of
   Excellence project (ICT-318488) supported by the European Commission
   under its Seventh Framework Programme.

Authors' Addresses

   Martin Bjorklund
   Tail-f Systems

   EMail: mbj@tail-f.com


   Juergen Schoenwaelder
   Jacobs University

   EMail: j.schoenwaelder@jacobs-university.de