coman                                                    P. van der Stok
Internet-Draft                                                consultant
Intended status: Informational                             June 28, 2013
Expires: December 30, 2013


                       CoAp Management Interfaces
                     draft-vanderstok-core-comi-00

Abstract

   The draft describes an interface based on CoAP to manage constrained
   devices.  Access to existing MIBs is included.  The proposed
   integration of CoAP with SNMP reduces the code size by removing an
   important part of the SNMP code.  The draft lists a set of CoMI
   objects that describe the operational settings of the applications on
   the device.  A majority of them is taken over from other drafts to
   provide one uniform CoMI based access.

Note

   Discussion and suggestions for improvement are requested, and should
   be sent to core@ietf.org.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 30, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



van der Stok            Expires December 30, 2013               [Page 1]


Internet-Draft                    CoMI                         June 2013


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  CoAP Interface  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  MIB binary Function Set . . . . . . . . . . . . . . . . . . .   5
     5.1.  SNMP architecture . . . . . . . . . . . . . . . . . . . .   5
     5.2.  CoMI binding  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  CoMI Objects Function Set . . . . . . . . . . . . . . . . . .   7
     6.1.  CoMI object binding . . . . . . . . . . . . . . . . . . .   7
     6.2.  CoMI MIB Function Set . . . . . . . . . . . . . . . . . .   8
   7.  CoMI objects  . . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Appendix A.  XML Schema for CoMI MIB  . . . . . . . . . . . . . .  12
   Appendix B.  XML Schema for CoMI objects  . . . . . . . . . . . .  14
     B.1.  Schema for MC groups  . . . . . . . . . . . . . . . . . .  14
     B.2.  Schema for CoAP binding . . . . . . . . . . . . . . . . .  14
     B.3.  Valid Schemas . . . . . . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   The Constrained RESTful Environments (CoRE) working group aims at
   Machine to Machine (M2M) applications such as smart energy and
   building control.

   Small M2M devices need to be managed in an automatic fashion to
   handle the large quantities of devices that are expected to be



van der Stok            Expires December 30, 2013               [Page 2]


Internet-Draft                    CoMI                         June 2013


   installed in future installations.  The management protocol of choice
   for Internet is SNMP [RFC3410] as is testified by the large number of
   Management Information Base (MIB) [RFC3418]  specifications currently
   published [STD0001].  More recently, he NETCONF protocol [RFC6241]
   was developed with an extended set of messages using XML [XML] as
   data format.  The data syntax is specified with YANG [RFC6020] and a
   mapping from Yang to XML is specified.  In [RFC6643]  SMIv2 syntax is
   expressed in Yang.  Contrary to SNMP and also CoAP, NETCONF assumes
   persistent connections for example provided by SSH.  The NETCONF
   protocol provides operations to retrieve, configure, copy, and delete
   configuration data-stores.  Configuring data-stores distinguishes
   NETCONF from SNMP which operates on standardized MIBs.

   The CoRE Management Interface (CoMI) is intended to work on
   standardized data-sets in a stateless client-server fashion and is
   thus closer to SNMP than to NETCONF.  Standardized data sets are
   necessary when small devices from different manufacturers are managed
   by applications originating from another set of manufacturers.
   Stateless communication is encouraged to keep communications simple
   and the amount of state information small in line with the design
   objectives of 6lowpan [RFC4944] [RFC6775]  , RPL [RFC6650] , and CoAP
   [I-D.ietf-core-coap].

   Currently, managed devices need to support two protocols: CoAP and
   SNMP each with its own security solution.  When the MIB can be
   accessed with the CoAP protocol, the SNMP protocol with its security
   provisioning can be replaced with the CoAP protocol
   [I-D.ietf-core-coap] and DTLS [RFC6347].  This arrangement
   significantly reduces memory requirements, simplifies the stack in
   the constrained device, and harmonizes applications development.  A
   CoAP device that needs management can include a set of existing MIBs
   and use CoMI to manipulate them.

   The objective of CoMI is to provide a CoAP based Function Set that
   reads and sets parameter values in devices, and acquires operational
   values that change with time.  It extends SNMP by providing an XML
   interface [XML] that allows more complex structures than the flat
   tables of SNMP.

   CoMI is intended for small devices.  The XML overhead can be
   prohibitive.  It is therefore recommended to transport EXI [EXI] in
   the payload.  In [EXI-measurement] it is shown that EXI can be an
   order of magnitude smaller than the equivalent XML representation.
   Actually, the EXI structure adds the overhead per data unit of an EXI
   event (indicates the type of the following XML element) with a size
   that depends on the number of EXI event types present in the schema
   and its frequency of occurrence.  In [JSON-XML] it is shown that
   memory and CPU usage for sending JSON encoded or XML encoded objects



van der Stok            Expires December 30, 2013               [Page 3]


Internet-Draft                    CoMI                         June 2013


   led on average to a 50% lower resource usage for JSON.  Consequently,
   from a resource utilization point of view EXI seems the right choice.

   The end goal of CoMI is to provide information exchange over the CoAP
   transport protocol in a uniform manner to approach the full
   management functionality as specified in
   [I-D.ersue-constrained-mgmt].  This memo collects existing management
   functions from several sources to uniformize their access.

3.  Terminology

   Core Management Interface (CoMI) specifies the profile of Function
   Sets which access CoMI objects with the pupose of managing the
   operation of constrained devices in a network.

4.  CoAP Interface

   In CoRE a group of links can constitute a Function Set. The format of
   the links is specified in [RFC6690].  This note specifies a
   Management Function Set. CoMI end-points that implement the CoMI
   management protocol support at least one discoverable management
   resource of resource type (rt) core.mg with path /mg, where mg is
   short-hand for management.  The mg resource has two sub-resources
   each accessible with a different path:

   o  MIB with path /mg/mib and a binary content format

   o  CoMI with path /mg/comi and an XML, EXI content format.

   The MIB resource is provided to enable a smooth transition from SNMP
   to CoMI.  The binary content is composed of BER encoded SNMP PDUs.
   The CoMI resource provides access to the CoMI objects.  CoMI objects
   include MIBs and the objects described in Section 7.  XML schemas
   describe the structure of the CoMI objects.  It is expected that
   given the verbosity of XML, CoMI messages will mostly use EXI.  The
   service provided by the CoMI server is to transfer from/to the
   constrained devices: (1) BER encoded SNMP PDUs from/to MIBs, and (2)
   EXI encoded data from/to CoMI objects including MIB objects.  The
   profile of the management function set, with IF=core.comi, is shown
   in the table below

   +-------------+--------------+------------------+-------------------+
   | name        | path         | RT               | Data Type         |
   +-------------+--------------+------------------+-------------------+
   | Management  | /mg          | core.mg          | n/a               |
   |             |              |                  |                   |
   | MIB binary  | /mg/mib      | core.mg.mib      | application/octet |
   |             |              |                  |                   |



van der Stok            Expires December 30, 2013               [Page 4]


Internet-Draft                    CoMI                         June 2013


   | CoMI        | /mg/comi     | core.mg.comi     | application/exi   |
   | objects     |              |                  |                   |
   |             |              |                  |                   |
   | CoMI MIB    | /mg/comi/mib | core.mg.comi.mib | application/exi   |
   +-------------+--------------+------------------+-------------------+


   It is intended that CoMI schemas will be developed independently for
   different management subjects or contexts.  That means that the value
   of the EXI event has a different meaning dependent on the
   accompanying schema file.  The set of schemas that will be used is
   annouced to the device, such that it can prepare the parsing tables
   in advance.

5.  MIB binary Function Set

   The MIB binary Function Set provides a CoAP interface to transport
   BER encoded SNMP PDUs.  Section 5.1 and Section 5.2 explain the
   structure of SNMP PDUs and their transport with CoMI.

5.1.  SNMP architecture

   The architecture of the Internet Standard management framework
   consists of:

   o  A data definition language that is referred to as Structure of
      Management Information (SMI)[RFC2578].

   o  The Management Information Base (MIB) which contains the
      information to be managed and is defined for each specific
      function to be managed [RFC3418].

   o  A protocol definition referred to as Simple Network Management
      Protocol (SNMP) [RFC3416].

   o  Security and administration that provides SNMP message based
      security on the basis of the user-based security model [RFC3414].

   Separation in modules was motivated by the wish to respond to the
   evolution of Internet.  The protocol part (SNMP) and data definition
   part (MIB) are independent of each other.  The separation has enabled
   the progressive passage from SNMPv1 via SNMPv2 to SNMPv3.  This draft
   leverages this separation to replace the SNMP protocol with a CoAP
   based protocol.

   The SNMP protocol supports seven types of access supported by as many
   Protocol Data Unit (PDU) types:




van der Stok            Expires December 30, 2013               [Page 5]


Internet-Draft                    CoMI                         June 2013


   o  Get Request, transmits a list of OBJECT-IDENTIFIERs to be paired
      with values.

   o  GetNext Request, transmits a list of OBJECT-IDENTIFIERs to which
      lexicographic successors are returned for table traversal.

   o  GetBulk Request, transmits a list of OBJECT-IDENTFIERs and the
      maximum number of expected paired values.

   o  Response, returns an error or the (OBJECT-IDENTIFIER, value) pairs
      for the OBJECT-IDENTIFIERs specified in Get, GetNext, GetBulk,
      Set, or Inform Requests.

   o  Set Request, transmits a list of (OBJECT-IDENTIFIERs, value) pairs
      to be set in the specified MIB object.

   o  Trap, sends an unconfirmed message with a list of (OBJECT-
      IDENTIFIERs, value) pairs to a notification requesting end-point.

   o  Inform Request, sends a confirmed message with a list of (OBJECT-
      IDENTIFIERs, value) pairs to a notification requesting end-point.

   The binding of the notification to a destination (left open in SNMP
   protocol) is discussed in Section 7.

5.2.  CoMI binding

   The payload is structured as specified by the ASN-1 notation
   presented in [RFC3416].  The request PDUs: Get, GetNext, GetBulk,
   Set, and Inform are sent with a Confirmable CoAP message.  The
   Response is piggy backed in the returned Acknowledgement message.
   The Trap is sent as a NON-confirmable CoAP message.  The URI of the
   destination CoMI end-point contains the destination identifier and
   the path /mg/bin.  The request PDUs: Get, GetNext, GetBulk are sent
   with CoAP message type GET, all other request PDUs are sent with CoAP
   message type PUT.  Strictly speaking the request-id in the SNMP PDU
   has the same function as the CoAP token.  Preferably, the value of
   request-id should be identical to the CoAP token.  An example request
   looks like:


   REQ: GET example.com/mg/mib/ (Content-Format: application/octet-stream)
   <BER encoded SNMP PDU>

   RES: 2.05 Content (Content-Format: application/octet-stream)
   <BER encoded SNMP PDU>





van der Stok            Expires December 30, 2013               [Page 6]


Internet-Draft                    CoMI                         June 2013


   The BER encoding implies that OBJECT-IDENTIFIER is encoded as a
   sequence of numbers which defines the place of the object in the ISO
   object tree [RFC2578].

6.  CoMI Objects Function Set

   Two XML, EXI based interfaces are supported by CoMI: (1) Reading/
   Writing CoMI objects with path /mg/comi/object, (2) Reading/Writing
   MIB variables with path /mg/comi/mib/variable.

6.1.  CoMI object binding

   The information, represented by the CoMI objects, is composed of the
   values of configuration parameters in a device.  A CoMI object has a
   name that identifies it uniquely within the device.  The type of a
   CoMI object MUST be described with an XML schema.  CoMI object names
   and schemas are standardized by the IETF or by other relevant
   Standards Developing Organizations (SDO).  The CoMI object name is
   expressed in the path.  The attributes of the CoMI object that need
   to be set or read are either expressed in the EXI payload of the
   message or in the path of the destination URI.  By expressing the
   attribute in the path the data transfer is limited to one resource.
   An EXI message can express a selection of attributes that need to be
   set or read.  For example, consider the object with name "Alarms" of
   type "alarmCount":


   <xs:complexType name="alarmCount">
     <xs:sequence>
       <xs:element name="Priority1" type="xs:integer"
                       minOccurs="0" maxOccurs="1"/>
      <xs:element name="Priority2" type="xs:integer"
                       minOccurs="0" maxOccurs="1"/>
     </xs:sequence>
   <xs:complexType>


   In the coming examples the format of the EXI contents follows the
   syntax proposed in [EXI-primer].  Retrieving the contents of
   attribute Priority1 by expressing the attribute in the path is
   possible with:










van der Stok            Expires December 30, 2013               [Page 7]


Internet-Draft                    CoMI                         June 2013


   REQ: GET example.com/mg/comi/Alarms/Priority1
           (Content-Format: application/exi)

   RES: 2.05 Content (Content-Format: application/exi)
   SE(alarmCount)SE(Priority1) value EE EE


   Retrieving the contents of Priority1 and Priority2 attributes by
   referring to the object as a whole in the URI is shown in the
   following example:


   REQ: GET example.com/mg/comi/Alarms

   RES: 2.05 Content (Content-Format: application/exi)
   SE(alarmCount) SE(priority1) value EE SE(priority2) value EE EE


   It is possible that the size of the specified object is too large to
   fit in a single message.  CoMI gives the possibility to send the
   contents of the objects in several fragments with a maximum size.
   The "sz" link-format attribute [RFC6690] specifies the maximum size
   in bytes.  The returned data MUST terminate with an EE EXI event.
   The sequel can be asked by sending the same request but with an
   offset that is equal to the already received number of EE EXI events.
   The offset is specified with the (new to define) "of" link-format
   attribute.

6.2.  CoMI MIB Function Set

   The Function Set allows the access to one MIB variable per CoAP
   message.  The schema is shown in Appendix A.  The identifier is based
   on the human readable name and not on the sequence of numbers that
   identifies the object in the ISO object hierachy.

   TODO: Distinguish CoMI objects of same type and thus with identical
   names.

   A request to read the value of a MIB variable is sent with a
   confirmable CoAP GET message.  A request to set a value is sent with
   a confirmable CoAP PUT message.  The Response is piggybacked to the
   CoAP ACK message corresponding with the Request.  An example request
   looks like:


   REQ: GET example.com/mg/comi/mib/variable

   RES: 2.05 Content (Content-Format: application/exi)



van der Stok            Expires December 30, 2013               [Page 8]


Internet-Draft                    CoMI                         June 2013


   SE(MIB)SE(name) variable EE SE(value) value EE EE


   A MIB variable may be composed of rows with each row composed of
   typed values.  Limits to the bulk transport are expressed with the
   "sz" link-format attribute [RFC6690] and the "of" link-format
   attribute.

   When a variable with the specified name cannot be processed by the
   SNMP server, CoAP Error code 5.01 is returned with the SNMP error
   code transported in the payload.  Two types of error code can be
   returned: exception or error-status as specified in Appendix A,
   according to the rules of [RFC3416].  For example when MIB "variable"
   does not exist:


   REQ: GET example.com/mg/comi/mib/variable

   RES: 5.01 Not Implemented (Content-Format: application/exi)
   SE(exception)noSuchObject EE


   The TRAP is sent with a non confirmable CoAP PUT message to a
   destination specified in Section 7.

7.  CoMI objects

   Setting up parameter values and establishing relations between
   devices during commissioning of a managed network is an important
   aspect of the deployment of CoMI objects.  Draft
   [I-D.ietf-core-interfaces] describes the binding of end-points to
   end-points on remote devices, and draft [I-D.ietf-core-groupcomm]
   describes the enabling of multicast messages.  A homogeneous approach
   to the associated resources is the subject of this section.  A list
   of objects describing different aspects of commissioning comprise:

   o  Binding table as described in [I-D.ietf-core-interfaces], schema
      presented in Appendix B.2.

   o  Multicast address enabling as described in
      [I-D.ietf-core-groupcomm], schema presented in Appendix B.1.

   o  SNMP notification destinations as referred to in [RFC3416], schema
      presented in Appendix B.2.

   o  Names of files containing the schemas to be expected, schema
      presented in Appendix B.3.




van der Stok            Expires December 30, 2013               [Page 9]


Internet-Draft                    CoMI                         June 2013


   The object with type "binding table" contains a sequence of bindings.
   The contents of bindings contains the methods, location, the interval
   specifications, and the step value as suggested in
   [I-D.ietf-core-interfaces].  The method "notify" has been added to
   the binding methods "poll", "obs" and "push", to cater for the
   binding of SNMP notifications to a target.

   The object of type "MCgroups" contains a sequence of MC addresses to
   be enabled on the interface, specified by MCentry.  In these schemas
   both the host name (group name) and the corresponding IP address are
   stored.  The IP address has been added for those networks where no
   access to DNS is possible and only the IP address is available.  Once
   the DNS is available and the IP address is brittle, it is recommended
   to use the host name and not rely on the value of the IP address.

   The object of type "Schema-files" contains a sequence of schema files
   describing the data structure tranportable in CoMI messages.

8.  security Considerations

   TODO: follows CoAP security provisioning.

9.  IANA Considerations

   TODO

10.  Acknowledgements

   Mehmet Ersue and Bert Wijnen explained the encoding aspects of PDUs
   transported under SNMP.  The draft has benefited from comments by Dee
   Denteneer, Esko Dijk, and Michael van Hartskamp.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.



van der Stok            Expires December 30, 2013              [Page 10]


Internet-Draft                    CoMI                         June 2013


   [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.

   [RFC3416]  Presuhn, R., "Version 2 of the Protocol Operations for the
              Simple Network Management Protocol (SNMP)", STD 62, RFC
              3416, December 2002.

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62, RFC
              3418, December 2002.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6643]  Schoenwaelder, J., "Translation of Structure of Management
              Information Version 2 (SMIv2) MIB Modules to YANG
              Modules", RFC 6643, July 2012.

   [RFC6650]  Falk, J. and M. Kucherawy, "Creation and Use of Email
              Feedback Reports: An Applicability Statement for the Abuse
              Reporting Format (ARF)", RFC 6650, June 2012.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, August 2012.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-17
              (work in progress), May 2013.




van der Stok            Expires December 30, 2013              [Page 11]


Internet-Draft                    CoMI                         June 2013


   [I-D.ietf-core-groupcomm]
              Rahman, A. and E. Dijk, "Group Communication for CoAP",
              draft-ietf-core-groupcomm-09 (work in progress), May 2013.

   [I-D.ietf-core-interfaces]
              Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf-
              core-interfaces-00 (work in progress), June 2013.

   [I-D.ersue-constrained-mgmt]
              Ersue, M., Romascanu, D., and J. Schoenwaelder,
              "Management of Networks with Constrained Devices: Problem
              Statement, Use Cases and Requirements", draft-ersue-
              constrained-mgmt-03 (work in progress), February 2013.

   [STD0001]  , "Official Internet Protocols Standard", Web
              http://www.rfc-editor.org/rfcxx00.html, .

   [EXI]      , "Efficient XML Interchange", Web
              http://www.w3.org/xml/exi, .

   [XML]      , "Extensible Markup Language (XML)", Web
              http://www.w3.org/xml, .

   [EXI-primer]
              Peintner, D. and S. Pericas-Geertsen, "EXI primer", Web
              http://www.w3.org/TR/exi-primer, december 2009.

   [EXI-measurement]
              White, G., KangaSharju, J., Williams, S., and D. Brutzman,
              "Efficient XML Interchange Measurements Note", Web
              http://www.w3.org/TR/2007/WD-exi-measurements-20070725,
              July 2007.

   [JSON-XML]
              Nurseitov, N., Paulson, M., Reynolds, R., and C.
              Inzurieta, "Comparison of JSON and XML Data Interchange
              Formats: A Case Study", Web
              http://www.cs.montana.edu/izurieta/pubs/caine2009.pdf,
              2009.

Appendix A.  XML Schema for CoMI MIB

   This appendix describes the XML schema that defines the payload
   contents for MIB requests via the CoMI Function Set.  It is assumed
   that MIB variables are referred by name and not by the oid.

   TODO: The schema needs to be updated to define basic types and
   notifications.  Access may be more sophisticated than described here.



van der Stok            Expires December 30, 2013              [Page 12]


Internet-Draft                    CoMI                         June 2013


   Creation and deletion of columns and rows is not catered for.  The
   access modes are not visible.


   <xs:simpleType name="exception">
      <xs:restriction base="xs:string">
        <xs:enumeration value="noSuchObject"/>
        <xs:enumeration value="noSuchInstance"/>
        <xs:enumeration value="endOfMibView"/>
      </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="error-status">
      <xs:restriction base="xs:string">
        <xs:enumeration value="noError"/>
        <xs:enumeration  value="tooBig"/>
        <xs:enumeration  value="noSuchName"/>
        <xs:enumeration  value="badValue"/>
        <xs:enumeration  value="readOnly"/>
        <xs:enumeration  value="genErr"/>
        <xs:enumeration  value="noAccess"/>
        <xs:enumeration  value="wrongType"/>
        <xs:enumeration  value="wrongLength"/>
        <xs:enumeration  value="wrongEncoding"/>
        <xs:enumeration  value="wrongValue"/>
        <xs:enumeration  value="noCreation"/>
        <xs:enumeration  value="inconsistentValue"/>
        <xs:enumeration  value="resourceUnavailable"/>
        <xs:enumeration  value="commitFailed"/>
        <xs:enumeration  value="undoFailed"/>
        <xs:enumeration  value="authorizationError"/>
        <xs:enumeration  value="notWritable"/>
        <xs:enumeration  value="inconsistentName"/>
      </xs:restriction>
   </xs:simpleType>


   <xs:complexType name ="MIBscalar">
   <xs:sequence>
      <xs:element name="identifier" type="xs:string"/>
     <choice>
           <xs:element name="value" type="xs:integer"/>
           <xs:element name="value" type="xs:string"/>
     </choice>
   </xs:sequence>
   </xs:complexType>

   <xs:complexType name="entryType">



van der Stok            Expires December 30, 2013              [Page 13]


Internet-Draft                    CoMI                         June 2013


   <xs:sequence>
        <xs:element name="Type" type="MIBscalar"
                   minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
   </xs:complexType>


   <xs:complexType name="MIBTable">
   <xs:sequence>
        <xs:element name="Entry" type="entryType"
                   minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
   </xs:complexType>





Appendix B.  XML Schema for CoMI objects

   This appendix describes the XML schema that defines the payload
   contents for requests via the CoMI Function Set to the CoMI objects
   for multicast group, binding table, and SNMP notifications.  For the
   SNMP notifications the Binding Method table specification of
   [I-D.ietf-core-interfaces]  has been extended with "notify".

B.1.  Schema for MC groups

   MCentries are stored in MCGroups


   <xs:complexType name="MCentry">
       <xs:element name="groupName" type="xs:string"/>
       <xs:element name="IPaddress" type="xs:string"/>
   </xs:complexType>

   <xs:complexType name="MCgroups">
   <xs:sequence>
         <xs:element name="MCentry" type="MCentry"
                   minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
   </xs:complexType>



B.2.  Schema for CoAP binding





van der Stok            Expires December 30, 2013              [Page 14]


Internet-Draft                    CoMI                         June 2013


   Binding table contains several simple Bindings, composed of timing
   parameters and Function signature.


   <xs:complexType name="CoAPmethod">
       <xs:restriction base="xs:string">
          <xs:enumeration value="GET"/>
          <xs:enumeration value="PUT"/>
          <xs:enumeration value="POST"/>
       </xs:restriction>
   </xs:complexType>

   <xs:complexType name="bindingMethod">
       <xs:restriction base="xs:string">
       <xs:enumeration value="poll"/>
       <xs:enumeration value="obs"/>
       <xs:enumeration value="push"/>
       <xs:enumeration value="notify"/>
       </xs:restriction>
   </xs:complexType>


   <xs:complexType name="invocation">
       <xs:element name="hostname" type="xs:string"/>
       <xs:element name="pathname" type="xs:string"/>
       <xs:element name="IPaddress" type="xs:string"/>
       <xs:element name="bindingMethod" type="bindingMethod"/>
       <xs:element name="CoAPmethod" type="CoAPmethod"/>
   </xs:complexType>

   <xs:complexType name="simpleBinding">
        <xs:element name="method" type="invocation"/>
        <xs:element name="minPeriod" type="xs:integer"/>
        <xs:element name="maxPeriod" type="xs:integer"/>
        <xs:element name="changeStep" type="xs:integer"/>
   </xs:complexType>

   <xs:complexType name="binding Table">
       <xs:sequence>
           <xs:element name="simpleBinding" type="simpleBinding"
                       minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
   </xs:complexType>



B.3.  Valid Schemas




van der Stok            Expires December 30, 2013              [Page 15]


Internet-Draft                    CoMI                         June 2013


   File names are stored in Schema


   <xs:complexType name="Schema-files">
   <xs:sequence>
         <xs:element name="Schema" type="xs:string"
                   minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
   </xs:complexType>



Author's Address

   Peter van der Stok
   consultant

   Phone: +31-492474673 (Netherlands), +33-966015248 (France)
   Email: consultancy@vanderstok.org
   URI:   www.vanderstok.org































van der Stok            Expires December 30, 2013              [Page 16]