Subject: [lmap] review: draft-ietf-lmap-information-model-00

From: "Bajpai, Vaibhav" <[email-masked]>
Date: Mon, 2 Jun 2014 06:52:11 +0000

Hello,

I made some notes while reading the information model document [1].
[1] http://tools.ietf.org/html/draft-ietf-lmap-information-model-00

Thought to share it along:

  Introduction
  ~~~~~~~~~~~~

  The main components of a large-scale measurement platform are the
  Measurement Agents (hereafter MAs), the Controller(s) and the Collector(s).
  The MAs are the elements actually performing the measurements.  The MAs are
  controlled by exactly one Controller at a time ...

a) A (controller) target is part of the instruction channel object. The
instruction channel object can be updated during the configuration. Can it
also be updated at any later point in time? I suppose through a separate
instruction object. However, the instruction object currently only refers to
report channels.

  Pre-Configuration Information
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  object {
     ma-channel-obj      ma-instruction-channel;
     ma-channel-obj      ma-ma-to-controller-channel;
     [urn                ma-device-id;]
     [uuid               ma-agent-id;]
  } ma-preconfig-obj;

a) MA needs a private key, should we add it here?

b) MA needs a CA bundle to validate peer-certificates, should we add it here?

c) MA needs a certificate to interact over the channels. There is a
certificate field within the channel object, but I suppose that certificate
refers to the remote endpoint. If it instead refers to the MA, then do we want
to allow the MA to authenticate using separate certificates over each channel?

d) Why do we use a URN namespace for a deviceID but not for a UUID? [rfc 4122]

e) The target is part of the channel object. Given, there are two channels
defined in the pre-configured object. A (misconfigured) MA can point to two
different controllers: controller1 (instruction channel) and controller2
(ma-to-controller channel). This may violate the assertion of a single
controller interaction at a given point in time as described in the Sec 1.

f) Is the pre-configured object a singleton object?

g) The device ID is optional. If the MA does not have a UUID pre-configured,
it needs to retrieve it via configuration. However, how will the controller
identify the MA if it does not supply a device ID? If the device ID is
considered optional for privacy reasons, then should it also not be optional
in the status object where it is currently mandatory?

  Configuration Information
  ~~~~~~~~~~~~~~~~~~~~~~~~~

  object {
     uuid                ma-agent-id;
     ma-channel-obj      ma-instruction-channel;
    [string              ma-group-id;]
    [boolean             ma-report-ma-id-flag;]
    [int                 ma-instruction-channel-failure-threshold;]
  } ma-config-obj;

a) MA ID is a UUID, but group ID is a string. If we want to use a string,
shall we call it group name?

b) The ma-to-controller channel object is missing in the configuration object.
If the controller can change the instruction channel, it should also be able
to change the ma-to-controller channel, no?

  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 also to be
  reported.

c) The report MA ID flag is optional. However, does ^ text mean that the flag
becomes mandatory when the group ID is used. Then I suggest to describe it as
a tuple:

  object {
     uuid                ma-agent-id;
     ma-channel-obj      ma-instruction-channel;
    [(string,boolean)    (ma-group-id, ma-report-ma-id-flag);]
    [boolean             ma-report-ma-id-flag);]
    [int                 ma-instruction-channel-failure-threshold;]
  } ma-config-obj;

  Instruction Information
  ~~~~~~~~~~~~~~~~~~~~~~~

  The nature and number of these Options will depend upon the Measurement Task
  and will be defined in the Measurement Task Registry.

Measurement Task Registry would be? perhaps a reference is missing here.

  object {
     string              ma-task-name;
     urn                 ma-task-registry;
     string              ma-task-options<0..*>;
    [string              ma-task-cycle-id;]
  } ma-task-obj;

a) From this point in the document, the objects have a name. We didn't have
names for objects defined previously. Are these names meant to uniquely
identify the instance?

b) Would it be useful to have a version number associated with a task object?
There is a measurement version associated with a capability object. Should we
increase the granularity to have version numbers for each task object?

  object {
     string              ma-schedule-task-name;
     ma-sched-report-obj ma-schedule-task-reports<0..*>;
  } ma-sched-task-obj;

c) I assume ma-schedule-task-name is an identifer of this object. In that
case, we may be missing a reference to a task object as (below).

  object {
     string              ma-schedule-task-name;
     ma-task-obj         ma-task-obj<0..*>;
     ma-sched-report-obj ma-schedule-task-reports<0..*>;
  } ma-sched-task-obj;

--

  object {
    [int                 ma-schedule-task-filter;]  // default: all
     string              ma-schedule-task-report-channel-name;
  } ma-sched-report-obj;

d) The ma-schedule-task-filter element is not described in the document.

e) Previously we were embedding channel objects. Now we are referring to them
by name. Additionally 'report-channel' in the name gives an impression that
all schedules report back to the reporting channel (collector). However, as
mentioned in the document some schedules can also send results back to the
controller (via the ma-to-controller channel). I suggest to change this object
to as (below)

  object {
    [int                 ma-schedule-task-filter;]  // default: all
     ma-channel-obj      ma-schedule-channel-obj;
  } ma-sched-report-obj;

--

  object {
     boolean             ma-suppression-enabled;
    [datetime            ma-suppression-start;] // default: immediate
    [datetime            ma-suppression-end;]   // default: indefinite
    [string              ma-suppression-task-names<0..*>;]
                         // default: all tasks if
                         // ma-suppression-task-names is empty
    [string              ma-suppression-schedule-names<0..*>;]
                         // default: all schedules if
                         // ma-suppression-schedule-names is empty
  } ma-suppression-obj;

f) Why do we use datetime objects to refer to start and end? Shall we not just
embed a timing-obj here? It's a nice reusable building block.  Otherwise we
will also need to add more elements like the timezone offset here.

  MA to Controller Information
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  object {
     uuid                ma-log-agent-id;
     datetime            ma-log-event-time;
     code                ma-log-code;
     string              ma-log-description;
  } ma-log-obj;

a) The purpose of ma-log-agent-id is not described in the document.

b) For the datetime object (as previously reasoned) why don't we just use a
timing-obj, otherwise we also need the timezone offset information.

c) Can we rename this section to "Logging Information"? The name "MA to
Controller Information" gives an impression that in other sections the MA does
not send information to the controller, but that may not be true. For
instance, the "Capability and Status Information" is also MA to controller
information.

  Capability and Status Information
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  object {
     uuid                ma-agent-id;
     urn                 ma-device-id;
     string              ma-hardware;
     string              ma-firmware;
     string              ma-software;
     ma-interface-obj    ma-interfaces<0..*>;

     datetime            ma-last-measurement;
     datetime            ma-last-report;
     datetime            ma-last-instruction;
     datetime            ma-last-configuration;

     ma-capability-obj   ma-supported-measurements<0..*>;
  } ma-status-obj;

a) The ma-device-id and ma-agent-id are mandatory. If the controller mandates
a ma-group-id with a report-ma-id-flag as false, do we still report the
ma-agent-id and ma-device-id in the status objects?

b) The description of some fields is missing. For instance, it's unclear what
should be reported in ma-software. Is it the version of the OS running on the
MA? or is the version of the LMAP protocol?

  object {
     string              ma-interface-name;
     string              ma-interface-type;
     int                 ma-interface-speed;  // mbps
     string              ma-link-layer-address;
     ip-address          ma-interface-ip-addresses<0..*>;
    [ip-address          ma-interface-gateways<0..*>;]
    [ip-address          ma-interface-dns-servers<0..*>;]
  } ma-interface-obj;

a) Is the link-layer address reporting mandatory?

  object {
     urn                 ma-measurement-id;
    [string              ma-measurement-version;]
  } ma-capability-obj;

a) The ma-measurement-id and ma-measurement-version fields are not described
in the document.

b) The ma-measurement-version I assume is to tag the version of tests running
the measurement? Would it not be useful to put this within the task-obj to
allow each test to have its own version?

c) The status objects and capability objects are intermingled with one
another.  Shall we just factor these two out separately? For once, the
capability information needs to be reported much earlier. The instruction
object can only be retrieved once the controller receives MA capabilities.
Secondly, capabilities are fairly static and may need to be less frequently
reported when compared to the status object. I suggest this refactor (below)

-- this can be introduced as a separate section between 3.3 and 3.4.

  object {
     uuid                ma-agent-id;
     urn                 ma-device-id;
     string              ma-hardware;
     string              ma-firmware;
     string              ma-software;
     ma-interface-obj    ma-interfaces<0..*>;
     ma-task-obj         ma-task-obj<0..*>;    // supported measurement tasks
  } ma-capability-obj;

-- this can remain here as section 3.6

  object {
     datetime            ma-last-measurement;
     datetime            ma-last-report;
     datetime            ma-last-instruction;
     datetime            ma-last-configuration;
  } ma-status-obj;

  Reporting Information
  ~~~~~~~~~~~~~~~~~~~~~

  object {
     datetime            ma-report-date;
    [uuid                ma-report-agent-id;]
    [string              ma-report-group-id;]
     ma-context-obj      ma-report-context<0..*>;
     ma-report-task-obj  ma-report-tasks<0..*>;
  } ma-report-obj;

a) Shall we just use a timing-obj? Otherwise we also need a timezone offset
field here.

b) Why is groupID a string but agentID is a UUID? There is a description in
3.3 how groupID could be a name, then shall we not call it group name?

  object {
     ma-task-obj         ma-report-task-config;
     string              ma-report-task-column-headers<0..*>;
     ma-result-row-obj   ma-report-task-rows<0..*>;
  } ma-report-task-obj;

  object {
     datetime            ma-report-result-time;
    [int                 ma-report-result-cross-traffic;]
     data                ma-report-result-values<0..*>;
  } ma-result-row-obj;

a) Shall we just use a timing-obj? Otherwise we also need a timezone offset
field here.

b) The description of ma-report-result-cross-traffic field is missing.

c) Isn't "data" very generic? Shall we call it a blob/clob?

  Channels
  ~~~~~~~~

  The
  certificate can be the digital certificate associated to the FQDN in
  the URL or it can be the certificate of the Certification Authority
  that was used to issue the certificate for the FQDN (Fully Qualified
  Domain Name) of the target URL (which will be retrieved later on
  using a communication protocol such as SSL).

a) /s/SSL/TLS?

  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.

a) Are names uniquely identifying the objects? In order to reference a object
from another, sometimes we embed it but sometimes we reference it by a name.
Can we please make this consistent?

  As for Measurement Tasks, multiple interfaces are also supported.  For
  example the Controller could choose to receive some results over GPRS.  This
  is especially useful when such results indicate the loss of connectivity on a
  different network interface.  Facility is also provided for the Controller to
  choose whether to receive empty reports where there is no Measurement Task
  information.  In some cases this may be desirable to monitor the health of the
  measurement system.

a) The text gives an impression that the controller receives the reports. I
think we mean that the controller chooses what reports are sent to the
collector, but it's currently confusing to read.

  object {
     string              ma-channel-name;
     url                 ma-channel-target;
     certificate         ma-channel-certificate;
     ma-timing-obj       ma-channel-timing;
    [string              ma-channel-interface-name;]
    [boolean             ma-channel-connect-always;]
                         // default: false
                         // (only connect when data is pending)
  } ma-channel-obj;

a) The certificate refers to the certificate of the MA or the remote endpoint
(controller/collector)? There are two peer certificates exchanged on the
channel, shall we not have two separate fields?

b) Does "certificate" mean an X.509 certificate?

c) It would be nice to have a description on "ma-channel-connect-always"
field? Is this field meant to allow persistent connections?

  Timing Information
  ~~~~~~~~~~~~~~~~~~

  object {
    [string              ma-timing-name;]
    union {
        ma-periodic-obj  ma-timing-periodic;
        ma-calendar-obj  ma-timing-calendar;
        ma-one-off-obj   ma-timing-one-off;
        ma-immediate-obj ma-timing-immediate;
    }
    [ma-randomness-obj   ma-timing-randomness;]
  } ma-timing-obj;

a) The ma-timing-name is optional here. Should we not use it to uniquely
identify this object?

  object {
    [datetime            ma-calendar-start;] // default: immediate
    [datetime            ma-calendar-end;]   // default: indefinite
    [int                 ma-calendar-months<0..*>;]   // default: 1-12
    [days                ma-calendar-weekdays<0..*>;] // default: all
    [int                 ma-calendar-hours<0..*>;]    // default: 0-23
    [int                 ma-calendar-minutes<0..*>;]  // default: 0-59
    [int                 ma-calendar-seconds<0..*>;]  // default: 0-59
    [int                 ma-calendar-timezone-offset;]
                         // default: system timezone offset
  } ma-calendar-obj;

a) The timezone-offset field should be part of the generic timing-obj, no?

b) Do we also need a field to determine if daylight saving time is in effect?

c) The definition of weekdays may get confusing. Would it better to rename
ma-calendar-weekdays to ma-calendar-days?

  Notation
  ~~~~~~~~

  An optional field is enclosed by [ ], and an array is indicated by two
  numbers in angle brackets, <m..n>>, where m indicates the minimal number of
  values, and n is the maximum.  The symbol * for n means no upper bound.

a) Most of the IM elements use <0..*> notation. What would be the difference
between an empty array <0> and an optional field using []?

b) It would also be nice to know how to uniquely identify an IM object.
Perhaps introducing the notation of underlining an item (or a set of items)
that can uniquely identify the instance.

  Organizational Changes
  ~~~~~~~~~~~~~~~~~~~~~~

a) How about starting out section 3 with a subsection on building blocks such
as : a) Timing objects and b) Channels. The other subsections may become
easier to read once these ideas are wired in the brain.

b) An enumerated description of what each field in each IM element means would
be nice. It is also not clear why some fields are chosen to be optional
against others.

  Editorial Changes
  ~~~~~~~~~~~~~~~~~

  /s/To from agreement/To form agreement

Best, Vaibhav

-----------------------------------------------------
Vaibhav Bajpai

Research I, Room 86
Computer Networks and Distributed Systems  (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com