Network Working Group                                       T. Burbridge
Internet-Draft                                                P. Eardley
Intended status: Informational                           British Telecom
Expires: April 24, 2014                                       M. Bagnulo
                                        Universidad Carlos III de Madrid
                                                       J. Schoenwaelder
                                                       Jacobs University
                                                        October 21, 2013

     Information Model for Large-Scale Measurement Platforms (LMAP)


   This Information Model applies to the Measurement Agent within a
   Large-Scale Measurement Platform.  As such it outlines the
   information that is (pre-)configured on the MA or exists in
   communications with a Controller or Collector within an LMAP
   framework.  The purpose of such an Information Model is to provide a
   protocol and device independent view of the MA that can be
   implemented via one or more Control and Report protocols.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

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

   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 April 19, 2014.

Copyright Notice

Burbridge, et al.        Expires April 19, 2014                 [Page 1]

Internet-Draft                   LMAP IM                    October 2013

   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
   ( 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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  LMAP Information Model . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Information Structure  . . . . . . . . . . . . . . . . . .  4
     2.2.  Pre-Configuration Information  . . . . . . . . . . . . . .  5
     2.3.  Configuration Information  . . . . . . . . . . . . . . . .  5
     2.4.  Instruction Information  . . . . . . . . . . . . . . . . .  6
     2.5.  Logging Information  . . . . . . . . . . . . . . . . . . .  9
     2.6.  Status Information . . . . . . . . . . . . . . . . . . . . 10
     2.7.  Reporting Information  . . . . . . . . . . . . . . . . . . 11
     2.8.  Channels . . . . . . . . . . . . . . . . . . . . . . . . . 12
     2.9.  Timing Information . . . . . . . . . . . . . . . . . . . . 13
       2.9.1.  Periodic Timing  . . . . . . . . . . . . . . . . . . . 14
       2.9.2.  Calendar Timing  . . . . . . . . . . . . . . . . . . . 14
       2.9.3.  One-Off Timing . . . . . . . . . . . . . . . . . . . . 15
       2.9.4.  Immediate Timing . . . . . . . . . . . . . . . . . . . 15
       2.9.5.  Timing Randomness  . . . . . . . . . . . . . . . . . . 15
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Burbridge, et al.        Expires April 19, 2014                 [Page 2]

Internet-Draft                   LMAP IM                    October 2013

1.  Introduction

   A large-scale measurement platform is a collection of components that
   work in a coordinated fashion to perform measurements from a large
   number of vantage points.  The main components of a large-scale
   measurement platform are the Measurement Agents (hereafter MAs), the
   Controllers and the Collectors.

   The MAs are the elements actually performing the measurements.  The
   MAs are controlled by one or more Controllers and the Collectors
   gather the results generated by the MAs.  In a nutshell, the normal
   operation of a large-scale measurement platform starts with the
   Controller instructing a set of MAs to perform a set of measurements
   at a certain point in time.  The MAs execute the instructions from
   the Controller and once they have done so they report the results of
   the measurements to the Collector.  The overall framework for a Large
   Measurement platform and the terminology used in this document is
   described in detail in [I-D.ietf-lmap-framework].

   A large-scale measurement platform involves basically three
   protocols, namely, a Control protocol between the Controller(s) and
   the MAs, a Report protocol between the MAs and the Collector(s) and
   several measurement protocols between the MAs used to actually
   perform the measurements.  In addition the some information is
   required to be provisioned to the MA prior to any comunication with
   the Controller.

   This document defines the information model for both the Control and
   the Report protocol along with pre-configuration information that is
   required before communicating with the Controller, broadly named as
   the LMAP Information Model (or LMAP IM for short).  The measurement
   protocols are out of the scope of this document.

   As defined in [RFC3444], the LMAP IM defines the concepts involved in
   a large-scale measurement platform at a high level of abstraction,
   independently of any specific implementation or actual protocol used
   to exchange the information.  It is expected that the proposed
   information model can be used with different protocols in different
   measurement platform architectures and across different types of MA
   device (e.g. home gateway, smartphone, PC, router etc.).

2.  LMAP Information Model

Burbridge, et al.        Expires April 19, 2014                 [Page 3]

Internet-Draft                   LMAP IM                    October 2013

2.1.  Information Structure

   The information described herein relates to the information stored,
   received or transmitted by a Measurement Agent as described within
   the LMAP framework [I-D.ietf-lmap-framework].  As such, some subsets
   of this information model are applicable to the measurement
   Controller, Collector and systems that pre-configure the Measurement
   Agent.  The information described in these models will be transmitted
   across the protocols and interfaces between the Measurement Agent and
   such systems according to a Data Model.

   For clarity the information model is divided into six sections:

   1.  Pre-Configuration Information.  Information pre-configured on the
       Measurement Agent prior to any communication with other
       components of the LMAP architecture, specifically detailing how
       to register with a Controller

   2.  Configuration Information.  Information delivered to the MA on
       registration with a Controller or updated during a later
       communication, in particular detailing how to retrieve
       measurement and reporting instruction information from a
       Controller along with information specifically about the MA

   3.  Instruction Information.  Information that is received by the MA
       from the Controller pertaining to the measurement and reporting
       configuration.  This includes measurement configuration, report
       channel configuration, measurement schedules and measurement
       suppression information

   4.  Logging Information.  Information transmitted from the MA to the
       Controller detailing the results of any configuration operations
       along with error and status information from the operation of the

   5.  Status Information.  Information on the general status and
       capabilities of the MA.  For example, the set of measurements
       that are supported on the device

   6.  Reporting Information.  Information transmitted from the MA to
       the Collector including measurement results and the context in
       which they were conducted

   In addition the MA may hold further information not described herein,
   and which may be optionally transferred to or from other systems
   including the Controller and Collector.  One example of information
   in this category is subscriber or line information that may be
   reported by the MA as optional fields in the reporting communication

Burbridge, et al.        Expires April 19, 2014                 [Page 4]

Internet-Draft                   LMAP IM                    October 2013

   to the Collector.

2.2.  Pre-Configuration Information

   This information is the minimal information that needs to be pre-
   configured to the MA in order for it to successfully communicate with
   a Controller during the registration process.

   This pre-configuration information needs to include an URL of the
   Controller where configuration information can be retrieved along
   with the security information required for the communication
   including the certificate of the Controller (or the certificate of
   the Certification Authority which was used to issue the certificate
   for the Controller) as well as the timing for that communication.
   All this is expressed as the Configuration Channel.  In addition to
   the Configuration Channel information, the MA's security information
   is configured which can be either a certificate and a private key or
   a password, depending on the security solution used.

   Detail of the information model elements:

   1.  MA MAC: MAC Address

   2.  Configuration Channel: Channel

   3.  MA Certificate: Certificate (optional)

   4.  MA ID: random UUID (optional)

   5.  MA password: string (optional)

   The detail of the Channel object is described later since it is
   common to several parts of the information model.

2.3.  Configuration Information

   During registration or at any later point at which the MA contacts
   the Controller, the choice of Controller and details for the timing
   of communication with the Controller can be changed.  For example the
   pre-configured Controller may be replaced with a specific Controller
   that is more appropriate to the MA device type, location of
   characteristics of the network (e.g. access technology type or
   broadband product).  The initial communication timing object may also
   be replaced with one more relevant to routine communications between
   the MA and the Controller.

   In addition the MA will be given further items of information that
   relate specifically to the MA rather than the measurements it is to

Burbridge, et al.        Expires April 19, 2014                 [Page 5]

Internet-Draft                   LMAP IM                    October 2013

   conduct or how to report results.  The assignment of an ID to the MA
   is mandatory.  Optionally a Group ID may also be given which
   identifies a group of interest to which that MA belongs.  For example
   the group could represent an ISP, broadband product, technology,
   market classification, geographic region, or a combination of
   multiple such characteristics.  Where the Measurement Group ID is set
   an additional flag (the Report MA ID flag) is required to control
   whether the Measurement Agent ID is to be reported.  This allows the
   MA to remain anonymous which may be particularly useful to prevent
   tracking of mobile MA devices.

   The configuration information will also contain information about
   different communication channels that the MA will have with different
   elements of the infrastructure.  Each channel specifies a URL,
   security information and timing information for the communication.

   Detail of the additional information model elements:

   1.  Measurement Agent ID: UUID

   2.  Measurement Group ID (optional): String

   3.  Report MA ID flag (optional): Boolean

   4.  Instruction Channel: Channel (DISCUSSION: shouldn't we split this
       into 4 different channels i.e. the Measurement Task Configuration
       channel, the Report Channel channel, the Measurement Schedules
       channel and the Measurement Suppression channel?)

   5.  Status Channel: Channel

   6.  Logging Channel: Channel

2.4.  Instruction Information

   The Instruction information model has four sub-elements:

   1.  Measurement Task Configurations: Set

   2.  Report Channels: Set

   3.  Measurement Schedules: Set

   4.  Measurement Suppression: Object

   Conceptually each Measurement Task Configuration defines the
   parameters of a Measurement Task that the Measurement Agent (MA) may
   perform at some point in time.  It does not by itself actually

Burbridge, et al.        Expires April 19, 2014                 [Page 6]

Internet-Draft                   LMAP IM                    October 2013

   instruct the MA to perform them at any particular time (this is done
   by a Measurement Schedule).

   Example:  A Measurement Task Configuration may configure a single
      Measurement Task for measuring UDP latency.  The Measurement Task
      Configuration could define the destination port and address for
      the measurement as well as the duration, internal packet timing
      strategy and other parameters (for example a stream for one hour
      and sending one packet every 500 ms).  It may also define the
      output type and possible parameters (for example the output type
      can be the 95th percentile mean) where the measurement task
      accepts such parameters.  It does NOT define when the task starts
      (this is defined by the Measurement Schedule element), so it does
      not by itself instruct the MA to actually perform this measurement

   The Measurement Task Configuration will include a local short name
   for reference by the Measurement Schedule, along with a registry
   entry [I-D.bagnulo-ippm-new-registry] that defines the Measurement
   Task.  The MA itself will resolve the registry entry to a local
   executable program.  In addition the Measurement Task is specialised
   through a set of configuration Options.  The nature and number of
   these Options will depend upon the Measurement Task and will be
   defined in the Measurement Task Registry.  In addition the
   Measurement Task Configuration may optionally also be given a
   Measurement Cycle ID.  The purpose of this ID is to easily identify a
   set of measurement results that have been produced by Measurement
   Tasks with comparable Options.  This ID is manually incremented when
   an Option change is implemented which could mean that two sets of
   results should not be directly compared.

   A Report Channel defines how to report results to a single Collector.
   Several Report Channels can be defined to enable results to be split
   or duplicated across different report intervals or destinations.
   E.g. a single Collector may have three Report Channels, one reporting
   hourly, another reporting daily and a third on which to send
   immediate results for on-demand measurement tasks.  The details of
   the Channel element is described later as it is common to several

   A Measurement Schedule contains the instruction from the Controller
   to the MA to execute a single or repeated series of Measurement
   Tasks.  Each Measurement Schedule contains basically three elements:
   a reference to a list of Measurement Task Configuration, a reference
   to a set of one or more Report Channels, and a timing object for the
   schedule.  The schedule basically states what measurement task to
   run, how to report the results, and when to run the measurement task.
   Multiple measurement tasks in the list will be executed in order with

Burbridge, et al.        Expires April 19, 2014                 [Page 7]

Internet-Draft                   LMAP IM                    October 2013

   minimal gaps.  Note that the Controller can instruct the MA to report
   to several Collectors by specifying several Report Channels.

   Example:  a Measurement Schedule references a single Measurement Task
      Configuration for the UDP latency defined in the previous example.
      It references the Report Channel in the previous example to send
      results immediately as available to the specified Collector.  The
      timing is specified to run the configured Measurement Task
      Configuration every hour at 23 minutes past the hour.

   Measurement Suppression information is used to over-ride the
   Measurement Schedule and stop measurements from the MA for a defined
   or indefinite period.  While conceptually measurements can be stopped
   by simply removing them from the Measurement Schedule, splitting out
   separate information on Measurement Suppression allows this
   information to be updated on the MA on a different timing cycle or
   protocol implementation to the Measurement Schedule.

   The goal when defining these four different elements is to allow each
   part of the information model to change without affecting the other
   three elements.  For example it is envisaged that the Report Channels
   and the set of Measurement Tasks Configurations will be relatively
   static.  The Measurement Schedule on the other hand is likely to be
   more dynamic as the measurement panel and test frequency are changed
   for various business goals.  Another example is that measurements can
   be suppressed with a Measurement Suppression command without removing
   the existing Measurement Schedules that would continue to apply after
   the Measurement Suppression expires or is removed.  In terms of the
   Controller-MA communication this can reduce the data overhead.  It
   also encourages the re-use of the same standard Measurement Task
   Configurations and Reporting Channels to help ensure consistency and
   reduce errors.

   Definition of the information model elements:

   1.  Measurement Task Configurations: Set

       1.  Measurement Task Configuration: Object

           1.  Task Name (used for referral from the Measurement
               Schedules): String

           2.  Registry Entry: URN

           3.  Options: Set (optional)

               1.  Interface name (reference by name to one of the
                   Interfaces defined in the Status information): String

Burbridge, et al.        Expires April 19, 2014                 [Page 8]

Internet-Draft                   LMAP IM                    October 2013

           4.  Measurement Cycle ID: String (optional)

   2.  Report Channels: Set

       1.  Report Channel: Channel

   3.  Measurement Schedules: Set

       1.  Measurement Schedule: Object

           1.  Schedule Name: String

           2.  Measurement Task Configuration Names (reference by Name
               to one of the measurement tasks defined in the
               Measurement Task Configuration set): List

               1.  Task Name: String

           3.  Report Channel Names (reference by Name to one of the
               measurement tasks defined in the Measurement Task
               Configuration set): Set

               1.  Channel Name: String

           4.  Measurement Timing: Timing

   4.  Measurement Suppression: Object (optional)

       1.  Start: datetime

       2.  End: datetime

       3.  Set of Measurement Task Configuration Names (optional -
           default all)

           1.  Task Name: String

2.5.  Logging Information

   The MA will report back success/failure and status information to the
   Controller.  These messages will fall into a number of different

   1.  Success/failure messages in response to information updates from
       the Controller.  For example:

       *  "Report Channel 'hourly db" configured"

Burbridge, et al.        Expires April 19, 2014                 [Page 9]

Internet-Draft                   LMAP IM                    October 2013

       *  "Measurement Schedule does not conform to schema, Row 211"

   2.  Status updates from the operation of the MA.  For example:

       *  "out of memory: cannot record result"

       *  "Collector '' not responding"

   Each log message will have the following Information model elements:

   1.  Log Time: datetime

   2.  Log Event: Object

2.6.  Status Information

   In addition to the information reported by the MA through the logging
   information, the MA will hold further status information that can be
   retrieved by a Controller.  One category of additional information
   that has not been defined in earlier sections is the availability of
   Measurement Tasks on that MA.

   MA Status information model elements:

   1.   MA ID: String

   2.   MA Device: String

   3.   MA hardware: String (optional)

   4.   MA firmware: String (optional)

   5.   MA software: String (optional)

   6.   MA Interfaces: set

        1.  If name: String

        2.  If type: String (one of eth, wlan, TBC)

        3.  If speed: Integer (expressed in Mbps)

        4.  Link Layer Address: String

        5.  IP address: Set

            1.  Protocol: String (one of v4, v6)

Burbridge, et al.        Expires April 19, 2014                [Page 10]

Internet-Draft                   LMAP IM                    October 2013

            2.  Address: String

        6.  Gateway: Set (optional)

            1.  Protocol: String (one of v4, v6)

            2.  Address: String

        7.  DNS server: Set (optional)

            1.  Protocol: String (one of v4, v6)

            2.  Address: String

   7.   Last Measurement: datetime

   8.   Last Report: datetime

   9.   Last Instruction: datetime

   10.  Last Configuration: datetime

   11.  Supported Measurements: Set

        1.  Registry Entry: URN

        2.  Version: String (optional)

2.7.  Reporting Information

   At a point in time specific by the Report Channel, the MA will
   communicate a set of measurement results to the Collector.  These
   measurement results should be communicated within the context in
   which they were collected.

   The report is structured hierarchically to avoid repetition of
   report, Measurement Agent and Measurement Task Configuration
   information.  The report starts with the timestamp of the report
   generation on the MA and details about the MA including the optional
   Measurement Agent ID and Group ID (controlled by the Configuration
   Information).  In addition optional further MA context information
   can be included at this point such as the line sync speed or ISP and
   product if known by the MA.

   After the MA information the results are reported grouped into the
   different Measurement Tasks.  Each Task starts with replicating the
   Measurement Task Configuration information before the result headers
   (titiles for data columns) and the result data rows.

Burbridge, et al.        Expires April 19, 2014                [Page 11]

Internet-Draft                   LMAP IM                    October 2013

   Information model elements:

   1.  Report Date: datetime

   2.  Measurement Agent ID: String (optional)

   3.  Measurement Group ID: String (optional)

   4.  MA Context: Set (optional)

       1.  Context Item: Object

   5.  Measurement Task: Set

       1.  Measurement Task Configuration: Object

       2.  Result Headers: List

           1.  Column Name: String

       3.  Result Data: List

           1.  Result Row: Object

               1.  Measurement Time: datetime

               2.  Cross-traffic: Integer (optional)

               3.  Result Columns: List

                   1.  Column Data

2.8.  Channels

   A Channel defines a communication channel between the MA and other
   element of the measurement framework i.e. with the Collector to
   report results back, to Controller to retrieve Instructions or other
   information exchanged between the parties.  Several Channels can be
   defined to enable results to be split or duplicated across different
   report intervals or destinations.  E.g. a single Collector may have
   three Report Channels, one reporting hourly, another reporting daily
   and a third on which to send immediate results for on-demand
   measurement tasks.

   Each Channel contains the details of the target (including location
   and security information such as the certificate), and the timing for
   the communication i.e. when to establish the communication.  The
   certificate can be the digital certificate associated to the FQDN in

Burbridge, et al.        Expires April 19, 2014                [Page 12]

Internet-Draft                   LMAP IM                    October 2013

   the URL or it can be the certificate of the Certification Authority
   that was used to issue the certificate for the FQDN of the target URL
   (which will be retrieved later on using a communication protocol such
   as SSL).  The Channel can use the same timing information object as a
   Measurement Schedule and the Controller Communication Timing defined
   earlier.  There are several options, such as immediately after the
   results are obtained or at a given interval or calendar based cycle).
   As with the Measurement task Configuration, each Channel is also
   given a local short name by which it can be referenced from a
   Measurement Schedule or other elements.

   Example:  A Channel using for reporting results may specify that
      results are to be sent to the URL
      (, using the appropriate digital
      certificate to establish a secure channel.  The Channel specifies
      that the results are to be sent immediately as available and not

   Channel: Object

   1.  Channel Name (used for referral from other objects ): String

   2.  Target: URL

   3.  Certificate: X.509 Certificate

   4.  Communication Timing: Timing

2.9.  Timing Information

   The Timing information object used throughput the information models
   can take one of four different forms:

   1.  Periodic.  Specifies a start, end and interval time in

   2.  Calendar: Specifies a calendar based pattern - e.g. 22 minutes
       past each hour of the day on weekdays

   3.  One Off: A single instance occurring at a specific time

   4.  Immediate: Should occur as soon as possible

   Optionally each of the first three options may also specify a
   randomness that should be evaluated and applied separately to each
   indicated event.

Burbridge, et al.        Expires April 19, 2014                [Page 13]

Internet-Draft                   LMAP IM                    October 2013

2.9.1.  Periodic Timing

   Information model elements:

   1.  1.  Timing Name: String

   2.  2.  Start: datetime (optional)

   3.  3.  End: datetime (optional)

   4.  4.  Interval: Integer (in milliseconds)

   5.  5.  Randomness: Timing Randomness (optional)

2.9.2.  Calendar Timing

   Information model elements:

   1.   Timing Name: String

   2.   Start: datetime (optional)

   3.   End: datetime (optional)

   4.   Months: Set (optional - default [1-12])

        1.  Month: Integer

   5.   Weekdays: Set (optional - default [Mon-Sun])

        1.  Weekday: String (one off Mon, Tue, Wed, Thu, Fri, Sat Sun)

   6.   Days: Set (optional - default [1-31])

        1.  Day: Integer

   7.   Hours: Set (optional - default [1-24])

        1.  Hour:Integer

   8.   Minutes: Set (optional - default [1-60])

        1.  Minute: Integer

   9.   Seconds: Set (optional - default [1-60])

        1.  Second: Integer

Burbridge, et al.        Expires April 19, 2014                [Page 14]

Internet-Draft                   LMAP IM                    October 2013

   10.  Randomness: Timing Randomness (optional)

2.9.3.  One-Off Timing

   Information model elements:

   1.  Time: datetime

   2.  Randomness: Timing Randomness (optional)

2.9.4.  Immediate Timing

   The immediate timing object has no further information elements.  The
   measurement or report is simply to be done as soon as possible.

2.9.5.  Timing Randomness

   The Timing randomness object specifies a random distribution that can
   be applied to any scheduled execution event such as a measurement or
   report.  The intention it to be able to spread the load on the
   Controller, Collector and network in an automated manner for a large
   number of Measurement Agents.  The randomness is expressed as a
   distribution (e.g.  Poison, Normal, Uniform etc.) along with the
   spread over which the distribution should be applied.  In additional
   optional upper and lower bounds can be applied to control extreme
   spread of timings.

   Information model elements:

   1.  Distribution: String

   2.  Upper Cut: Integer (optional)

   3.  Lower Cut: Integer (optional)

   4.  Spread: Integer

3.  IANA Considerations

   This document makes no request of IANA .

   Note to RFC Editor: this section may be removed on publication as an

Burbridge, et al.        Expires April 19, 2014                [Page 15]

Internet-Draft                   LMAP IM                    October 2013

4.  Security Considerations

   This Information Model deals with information about the control and
   reporting of the Measurement Agent.  There are broadly two security
   considerations for such an Information Model.  Firstly the
   Information Model has to be sufficient to establish secure
   communication channels to the Controller and Collector such that
   other information can be sent and received securely.  The second
   consideration is that no mandated information items pose a risk to
   confidentiality or privacy given such secure communication channels.
   For this latter reason items such as the MA context and MA ID are
   left optional and can be excluded from some deployments.  This would,
   for example, allow the MA to remain anonymous and for information
   about location or other context that might be used to identify or
   track the MA to be ommitted or blurred.

5.  Acknowledgements

6.  Informative References

              Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
              A. Morton, "A registry for commonly used metrics",
              draft-bagnulo-ippm-new-registry-00 (work in progress),
              January 2013.

              Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
              Aitken, P., and A. Akhter, "A framework for large-scale
              measurement platforms (LMAP)",
              draft-ietf-lmap-framework-00 (work in progress),
              October 2013.

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

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444,
              January 2003.

Burbridge, et al.        Expires April 19, 2014                [Page 16]

Internet-Draft                   LMAP IM                    October 2013

Authors' Addresses

   Trevor Burbridge
   British Telecom
   Adastral Park, Martlesham Heath
   Ipswich,   IP5 3RE


   Philip Eardley
   British Telecom
   Adastral Park, Martlesham Heath
   Ipswich,   IP5 3RE


   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid,   28911


   Juergen Schoenwaelder
   Jacobs University


Burbridge, et al.        Expires April 19, 2014                [Page 17]