Subject: [lmap] Feedback on draft-ietf-lmap-information-model

From: Benoit Claise <[email-masked]>
Date: Mon, 15 Sep 2014 00:38:32 +0200

Dear all,

Since we will be spending time on draft-ietf-lmap-information-model 
tomorrow, here is some more feedback. I haven't had the time to review 
it all, so here is part 1.
If some points were already discussed, don't hesitate to let me know.

> Network Working Group                                       T. Burbridge
> Internet-Draft                                                P. Eardley
> Intended status: Standards Track                                      BT
> Expires: February 21, 2015                                    M. Bagnulo
>                                         Universidad Carlos III de Madrid
>                                                         J. Schoenwaelder
>                                                 Jacobs University Bremen
>                                                          August 20, 2014
>
>
>      Information Model for Large-Scale Measurement Platforms (LMAP)
>                   draft-ietf-lmap-information-model-02
What does LMAP stand for?
In the use cases draft, it says "Large-scale Measurement of Broadband 
Performance (LMAP)"
Both the framework and the information model say: Large-Scale 
Measurement Platforms (LMAP)

>
> Abstract
>
>    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",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    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 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 February 21, 2015.
>
>
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 1]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
> Copyright Notice
>
>    Copyright (c) 2014 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
>    (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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>    2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
>    3.  LMAP Information Model  . . . . . . . . . . . . . . . . . . .   4
>      3.1.  Information Structure . . . . . . . . . . . . . . . . . .   4
>      3.2.  Pre-Configuration Information . . . . . . . . . . . . . .   8
>      3.3.  Configuration Information . . . . . . . . . . . . . . . .   9
>      3.4.  Instruction Information . . . . . . . . . . . . . . . . .  11
>      3.5.  Logging Information . . . . . . . . . . . . . . . . . . .  13
>      3.6.  Capability and Status Information . . . . . . . . . . . .  15
>      3.7.  Reporting Information . . . . . . . . . . . . . . . . . .  17
>      3.8.  Schedules . . . . . . . . . . . . . . . . . . . . . . . .  18
>      3.9.  Channels  . . . . . . . . . . . . . . . . . . . . . . . .  21
>      3.10. Task Configurations . . . . . . . . . . . . . . . . . . .  22
>      3.11. Timing Information  . . . . . . . . . . . . . . . . . . .  23
>        3.11.1.  Periodic Timing  . . . . . . . . . . . . . . . . . .  24
>        3.11.2.  Calendar Timing  . . . . . . . . . . . . . . . . . .  25
>        3.11.3.  One-Off Timing . . . . . . . . . . . . . . . . . . .  26
>        3.11.4.  Immediate Timing . . . . . . . . . . . . . . . . . .  26
>        3.11.5.  Startup Timing . . . . . . . . . . . . . . . . . . .  26
>    4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
>    5.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
>    6.  Appendix: JSON Example  . . . . . . . . . . . . . . . . . . .  27
>    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  35
>    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
>      8.1.  Normative References  . . . . . . . . . . . . . . . . . .  35
>      8.2.  Informative References  . . . . . . . . . . . . . . . . .  35
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35
>
>
>
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 2]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
> 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
>    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 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 one or more MAs to perform a
>    set of one or more Measurement Tasks at a certain point in time.  The
>    MAs execute the instructions from a Controller, and once they have
>    done so, they report the results of the measurements to one or more
>    Collectors.  The overall framework for a Large Measurement platform
>    as 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 a Controller and the
Control Protocol
> MAs, a Report protocol between the MAs and the Collector(s) and
>    several measurement protocols between the MAs and Measurement Peers
>    (MPs), used to actually perform the measurements.  In addition some
>    information is required to be configured on the MA prior to any
>    communication with the initial Controller.
"initial" confused me.
It's only later (section 3.3) that I understood that the Controller 
could be changed.
Candidate for removal, improvement, or forward reference?
>
>    This document defines the information model for both the Control and
>    the Report protocol along with pre-configuration information that is
>    required 
add "on the MA"
> before communicating with the Controller, broadly named as
>    the LMAP Information Model.  The measurement protocols are out of the
>    scope of this document.
>
>    As defined in [RFC3444], the LMAP IM defines the concepts involved in
IM = Information Model
this is the first occurrence.

>    a large-scale measurement platform at a high level of abstraction,
>    independent 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
>    devices (e.g., home gateway, smartphone, PC, router).
>
>    The definition of an Information Model serves a number of purposes:
>
>    1.  To guide the standardisation of one or more Control and Report
>        protocol and data model implementations
>
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 3]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>    2.  To enable high-level inter-operability between different Control
>        and Report protocols by facilitating translation between their
>        respective data models such that a Controller could instruct sub-
>        populations of MAs using different protocols
>
>    3.  To form agreement of what information needs to be held by an MA
>        and passed over the Control and Report interfaces and support the
>        functionality described in the LMAP framework
>
>    4.  Enable existing protocols and data models to be assessed for
>        their suitability as part of a large-scale measurement system
>
> 2.  Notation
>
>    This document use an object-oriented programming-like notation to
>    define the parameters (names/values) of the objects of the
>    information model.  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.
>
> 3.  LMAP Information Model
>
> 3.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]. 
Should the framework be normative? I believe so, specifically when I see 
all those Capitalized terms that are only defined in the framework.
This leads to another point. You miss a terminology section because some 
terms are specific to this document. Example: Task Suppression.
> As such, some subsets
>    of this information model are applicable to the measurement
>    Controller, Collector 
add a ","
Otherwise we can believe that the Collector could pre-configure the MA.
> and systems that pre-configure the Measurement
>    Agent.  The information described in these models will be transmitted
>    by protocols using 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 (i.e., the Controller,
>        Collector and Measurement Peers), specifically detailing how to
>        communicate with a Controller and whether the device is enabled
>        to participate as an MA.
>
>    2.  Configuration Information.  Update of the pre-configuration
>        information during the registration of the MA or subsequent
>        communication with the Controller, along with the configuration
>        of further parameters about the MA (rather than the Tasks it
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 4]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>        should perform) that were not mandatory for the initial
>        communication between the MA and a Controller.
>
>    3.  Instruction Information.  Information that is received by the MA
>        from the Controller pertaining to the Tasks that should be
>        executed.  This includes the task execution Schedules (other than
>        the Controller communication Schedule supplied as
>        (pre)configuration information) and related information such as
>        the Task Configuration, communication Channels to Collectors and
>        schedule Timing information.  It also inlcudes Task Suppression
>        information that is used to over-ride normal Task execution
>        during emergency situations.
>
>    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
>        MA.
>
>    5.  Capability and 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
>        one or more Collectors 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
>    extracted by a task and reported by the MA in the reporting
>    communication to a Collector.
>
>    It should also be noted that the MA may be in communication with
The "MA" or the "MA device"?
I'm asking because the rest of the sentence speaks about "configuring", 
and we said that MA can only be configured by one and only one Controller.
> other management systems which may be responsible for configuring and
>    retrieving information from the MA device.  Such systems, where
>    available, can perform an important role in transferring the pre-
>    configuration information to the MA or enabling/disabling the
>    measurement functionality of the MA.
"such systemS" ... "enabling/disabling the measurement functionality of 
the MA."
This is not possible. See my previous point.
>
>    The Information Model is divided into sub-sections for a number of
>    reasons.  Firstly the grouping of information facilitates reader
>    understanding.  Secondly, the particular groupings chosen are
>    expected to map to different protocols or different transmissions
>    within those protocols.
>
>    The granularity of data transmitted in each operation of the Control
>    and Report Protocols is not dictated by the Information Model. For
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 5]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>    example, the Instruction object may be delivered in a single
>    operation.  Alternatively, Schedules and Task Configurations may be
>    separated or even each Schdule/Task Configuration may be delivered
>    individually.  Similarly the Information Model does not dictate
>    whether data is read, write, or read/write.  For example, some
>    Control Protocols may have the ability to read back Configuration and
>    Instruction information which have been previosuly set on the MA.
>    Lastly, while some protocols may simply overwrite information (for
>    example refreshing the entire Instruction Information), other
>    protocols may have the ability to update or delete selected items of
>    information.
>
>    The information in these six sections is captured by a number of
>    common information objects.  These objects are also described later
>    in this document and comprise of:
>
>    1.  Schedules.  A set of Schedules tell the MA to do something.
>        Without a Schedule no Task (from a measurement to reporting or
>        communicating with the Controller) is ever executed. Schedules
>        are used within the Instruction to specify what tasks should be
>        performed, when, and how to direct their results.  A Schedule is
>        also used within the pre-Configuration and Configuration
>        information in order to execute the Task or Tasks required to
>        communicate with the Controller.
>
>    2.  Channels.  A set of Channel objects are used to communicate with
>        a number of endpoints (i.e. the Controller and Collectors). 
OLD: (i.e. the Controller and Collectors).
NEW: (the Controller, Collectors, and MAs).

These are the only 3 possibilities, right?
Logging always goes to the Collector, right?

> Each
>        Channel object contains the information required for the
>        communication with a single endpoint such as the target location
>        and security details.  Channels are referenced from within
>        Schedules in order to say how Tasks should communicate.
>
>    3.  Task Configurations.  A set of Task Configurations is used to
>        configure the Tasks that are run by the MA.  This includes the
>        registry entry for the Task and any configuration parameters.
>        Task Configurations are referenced from a Schedule in order to
>        specify what Tasks the MA should execute.
>
>    4.  Timings.  A set of Timing objects that can be referenced from the
>        Schedules.  Each Schedule always references exactly one Timing
>        object.  A Timing object specfies either a singleton or series of
>        time events.  They are used to indicate when Tasks should be
>        executed.
>
>    The following diagram illustrates the structure in which these common
>    information objects are referenced.  The references are achieved by
>    each object (Channel, Task Configuration, Timing) being given a short
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 6]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>    text name that is used by other objects.  The objects shown in
>    parenthesis are part of the internal object structure of a Schedule.
>
>           Schedule
>               |----------> Timing
>               |----------> (Scheduled Tasks)
>                                    |----------> Task Configuration
>                                    |----------> (Task Channels and 
> downstream Tasks)
> |----------> Channels
> |----------> Downstream Tasks
Please number the figures.

Why is only "configuration" mentioned in the figure?
I understood that everything is now a task:
     controller communication
     reporting
     measurement
     data aggregation
     ...
This was confusing to me.

>
>    It should be clear that the top-level bahaviour of an MA is simply to
>    execute Schedules.  Every action referenced by a Schedule is defined
>    as a Task.  As such, these actions are configured through Task
>    Configurations and executed according to the Timing referenced by the
>    Schedule in which they appear.  Tasks can implement a variety of
>    different types of actions.  While in terms of the Information Model,
>    all Tasks have the same structure, it can help conceptually to think
>    of different Task categories:
>
>    1.  Measurement Tasks
>
>        A.  Measurement Tasks measure some aspect of network performance
>            or traffic
>
>        B.  Data Capture Tasks capture and analyse passive information
Why capture? We can analyse without capture.
> stored on the MA device such as counters and device/network
>            status information

Why not traffic?
 From the charter:

    Both active and passive measurements are in scope, although there
    may be differences in their applicability to specific use cases, or
    in the security measures needed according to the threats specific to
    each measurement category

>
>    2.  Data Transfer Tasks
>
>        A.  Reporting Tasks report the results or Measurement Tasks to
>            Collectors
"Reporting Tasks report Measurement Tasks to Collectors"
Really? So the Controller configures the Reporting Tasks on the MA, and 
the MA reports them to the Collector?

Maybe you meant?
        A.  Reporting Tasks report the results _of _Measurement Tasks to
            Collectors
>
>        B.  Control Task(s) implement the Control Protocol and
>            communicate with the Controller.  Depending on the Control
>            Protocol this may be a number of specialist tasks such as:
What is "this"?
> Configuration Task; Instruction Task; Suppression Task;
>            Capabilities Task; Logging Task etc.
>
>    3.  Data Analysis Tasks can exist to analyse data from other
>        Measurement Tasks locally on the MA
>
>    4.  Data Management Tasks may exist to clean-up, filter or compress
>        data on the MA such as Measurement Task results
>
>
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 7]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
> 3.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. 
In section 3.1, we learned:

    1.  Pre-Configuration Information.  Information pre-configured on the
        Measurement Agent prior to any communication with other
        components of the LMAP architecture (i.e., the Controller,
        Collector and Measurement Peers), specifically detailing how to
        communicate with a Controller and whether the device is enabled
        to participate as an MA.

So the pre-configuration information is only for the Controller 
communication (I guess so) or also for the collector and measurement peers?
> The pre-configuration
>    information is a subset of the Configuration Information along with
>    some parameters that are not under the control of the LMAP framework
>    (such as the the device identifier and device security credentials).
I can't parse "not under the control of the LMAP framework"
>
>    This pre-configuration information needs to include a URL of the
>    initial Controller where configuration information can be retrieved
OLD: retrieved
NEW: communicated
NEW (alternative): pulled or pushed

Justification: the next paragraphs make the distinction.
> 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).  All this is expressed as a Channel. While
>    multiple Channels may be provided in the pre-configuration
>    information they must all be associated with a single Controller
>    (e.g. over different interfaces or network protocols).
>
>    Where the MA pulls information from the Controller, the Pre-
>    Configuration Information also needs to contain the timing of the
>    communication with the Controller as well as the nature of the
>    communication itself (such as the protocol and data to be
>    transfered).  The timing is given as a Schedule that executes the
>    Task(s) responsible for communication with the Controller.  It is
>    this Task (or Tasks) that implement the Control protocol between the
>    MA and the Controller.  The Task(s) may take additional parameters in
>    which case a Task Configuration can also be included.
>
>    Even where information is pushed to the MA from the Controller
>    (rather than pulled by the MA), a Schedule still needs to be
>    supplied.  In this case the Schedule will simply execute a Controller
>    listener task when the MA is started.  A Channel is still required
>    for the MA to establish secure communication with the Controller.
>
>    It can be seen that these Channels, Schedules and Task Configurations
>    for the initial MA-Controller communication are no different in terms
>    of the Information Model to any other Channel, Schedule or Task
>    Configuration that might execute a Measurement Task or report the
>    measurement results (as described later).
>
>    The MA may be pre-configured with an MA ID, or may use a Device ID in
>    the initial Controller contact before it is assigned an MA ID. 
Again, I'm confused by this initial Controller.

> The
>    Device ID may be a MAC address or some other device identifier
>    expressed as a URN.  If the MA ID is not provided at this stage then
>    it must be provided by the Controller during Configuration.
>
>    Detail of the information model elements:
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 8]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
> // MA pre-configuration minimal information to communicate initially 
> with Controller
>
> object {
>     [uuid                ma-agent-id;]
>      ma-task-obj         ma-control-tasks<1..*>;
>      ma-channel-obj      ma-control-channels<1..*>;
>      ma-schedule-obj     ma-control-schedules<1..*>;
>     [urn                 ma-device-id;]
>      credentials         ma-credentials;
> } ma-config-obj;
>
>    The detail of the Channel and Schedule objects are described later
>    since they are common to several parts of the information model.
>
> 3.3.  Configuration Information
>
>    During registration or at any later point at which the MA contacts
>    the Controller (or vice-versa), the choice of Controller, 
"The choice of Controller", do you want to say "an alternate 
Controller", because at this point the MA is already in contact with the 
Controller.
> details for
>    the timing of communication with the Controller or parameters for the
>    communication Task(s) can be changed (as captured by the Channels,
>    Schedules and Task Configurations objects).  For example the pre-
>    configured Controller (specified as a Channel or Channels) may be
>    replaced with a specific Controller that is more appropriate to the
>    MA device type, location or characteristics of the network (e.g.
>    access technology type or broadband product).  The initial
>    communication Schedule may be replaced with one more relevant to
>    routine communications between the MA and the Controller.
>
>    While some Control protocols and uses may only use a single Schedule,
>    other protocols and uses may uses several Schedules (and related data
>    transfer Tasks) to update the Configuration Information, transfer the
>    Instruction Information, transfer Capability and Status Information
>    and send other information to the Controller such as log or error
>    notifications.  Multiple Channels may be used to communicate with the
>    same Controller over multiple interfaces (e.g. to send logging
>    information over a different network).
>
>    In addition the MA will be given further items of information that
>    relate specifically to the MA rather than the measurements it is to
>    conduct or how to report results.  The assignment of an ID to the MA
>    is mandatory.  If the MA Agent ID was not optionally provided during
>    the pre-configuration then one must be provided by the Controller
>    during Configuration.  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
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 9]
> 
> Internet-Draft           LMAP Information Model August 2014
>
>
>    whether the Measurement Agent ID is also to be reported.  The
>    reporting of a Group ID without the MA ID allows the MA to remain
>    anonymous, which may be particularly useful to prevent tracking of
>    mobile MA devices.
>
>    Optionally an MA can also be configured to stop executing any
>    Instruction Schedule if the Controller is unreachable.  This can be
>    used as a fail-safe to stop Measurement and other Tasks being
>    conducted when there is doubt that the Instruction Information is
>    still valid.  This is simply represented as a time window in
>    milliseconds since the last communication with the Controller after
>    which Instruction Schedules are to be suspended.  The appropriate
>    vaue of the time window will depend on the specified communication
value
> Schedule with the Controller and the duration for which the system is
>    willing to tolerate continued operation with potentially stale
>    Instruction Information.
>
>    While pre-configuration is persistent upon device reset or power
>    cycle due to its very nature, the persistency of the addtional
>    configuration information may be control protocol dependent. 
Why "Control Protocol" dependent?
Why isn't the persistence IM (or DM) specific?
> Some
>    protocols may assume that reset devices will revert back to their
>    pre-configuration state, while other protocols may assume that all
>    configuration and instruction information is held in persistent
>    storage.
>
>    It should be noted that control shedules and tasks cannot be
>    suppressed as evidenced by the lack of suppression information in the
>    Configuration.  The control schedule must only reference tasks listed
>    as control tasks.  Any suppress-by-default flag against control tasks
>    will be ignored.
>
>    Detail of the additional and updated information model elements:
>
>    // MA Configuration
>
>    object {
>        uuid                ma-agent-id;
>       [ma-task-obj         ma-control-tasks<0..*>;]
>        ma-channel-obj      ma-control-channels<1..*>;
>       [ma-schedule-obj    ma-control-schedules<0..*>];
>       [urn                 ma-device-id;]
>        credentials         ma-credentials;
>       [string              ma-group-id;]
>       [boolean             ma-report-ma-id-flag;]
>       [int                 ma-control-channel-failure-threshold;]
>    } ma-config-obj;
>
>
That's where I arrived.

And now, time for a Guinness or two. I'm in Dublin after all :-)

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Mon, 15 Sep 2014 15:41:08 +0200

Dear all,

A generic point about the information model: I find it difficult to see 
how the objects are related since they are spread all over the document.
See how all classes were grouped in a single place in the EMAN 
framework: http://tools.ietf.org/html/rfc7326#section-7

Regards, Benoit
> Should the framework be normative? I believe so, specifically when I 
> see all those Capitalized terms that are only defined in the framework.
> This leads to another point. You miss a terminology section because 
> some terms are specific to this document. Example: Task Suppression.
>> As such, some subsets
> I'm asking because the rest of the sentence speaks about 
> "configuring", and we said that MA can only be configured by one and 
> only one Controller.
> "such systemS" ... "enabling/disabling the measurement functionality 
> of the MA."
>     may be differences in their applicability to specific use cases,
>     or in the security measures needed according to the threats
>     specific to each measurement category
>
>
>>
>>    2.  Data Transfer Tasks
>>
> Really? So the Controller configures the Reporting Tasks on the MA, 
> and the MA reports them to the Collector?
>
> Maybe you meant?
> Controller", because at this point the MA is already in contact with 
> the Controller.
>> details for

---

From: Benoit Claise <[email-masked]>
Date: Mon, 15 Sep 2014 22:43:59 +0200

Dear all,

Here is part 2.

Again, if some points were already discussed, don't hesitate to let me know.
See in-line.

Regards, Benoit

.3.3.  Configuration Information
>    the Controller (or vice-versa), the choice of Controller, details for
>    still valid. 
That makes sense, but have you considered the following case: when the 
Reporter is not available? Should the MA store all the reports? Will it 
have enough memory/space? What if it can't store it (memory/space).
If I take IPFIX as a specific LMAP platform, it's key to push the flow 
records (read Measurement Reports) as soon as possible.
Maybe this case is discussed in the framework draft?

Note that this would be another easy suppression mechanism: stopping the 
Reporting Channel

> This is simply represented as a time window in
>    configuration information may be control protocol dependent. Some
"additional and updated"?
> Burbridge, et al.       Expires February 21, 2015 [Page 10]
> 
> 3.4.  Instruction Information
>
>    The Instruction information model has four sub-elements:
>
>    1.  Instruction Task Configurations
>
>    2.  Report Channels
>
>    3.  Instruction Schedules
>
>    4.  Suppression
>
>    The Instruction supports the exceution of all Tasks on the MA except
execution
> those that deal with communication with the Controller (specified in
>    (pre)configuration information).  The Tasks are configured in
>    Instruction Task Configurations and inlcuded by reference in
included.
> Instruction Schdules that specify when to execute them.  The results
Schedules
 From now, I will stop mentioned spelling mistakes. I advice you to run 
the draft through a spell checker.
>    are communicated to other Tasks or over Report Channels.  Suppression
>    is used to temporarily stop the excution of new Tasks as specified by
>    the Instruction Schedules (and optionaly to stop ongoing Tasks).
>
>    A Task Configuration is used to configure the optional parameters of
>    a Task. 
Why "optional"? How are the non-optional parameters configured then?
Is there a difference between Task Configuration and Instruction Task 
Configurations?
> It also serves to instruct the MA about the Task including
>    the ability to resolve the Task to an executable and specifying the
>    schema for the Task parameters.
>
>    A Report Channel defines how to communicate with a single remote
>    system specified by a URL.  A Report Channel is used to send results
>    to single Collector but is no different in terms of the Information
>    Model to the Control Channel used to transfer information between the
>    MA and the Controller.  Several Report Channels can be defined to
>    enable results to be split or duplicated across different
>    destinations. 
The two sentences above are contradictory:
     to single Collector
     duplicated across different destinations.

> A single Channel can also be used by multiple
>    Schedules to transfer data at different cycles to the same Collector.
>    E.g. a single Collector may receive data at three different cycle
>    rates, one Schedule reporting hourly, another reporting daily and a
>    third specifying that results should be sent immediately for on-
>    demand measurement tasks.  Alternatively multiple Report Channels can
>    be used to send Measurement Task results to different Collectors.
>    The details of the Channel element is described later as it is common
>    to several objects.
>
>    Instruction Schedules specify which Tasks to execute according to a
>    given Timing (that can execute a single or repeated series of Tasks).
>    The Schedule also specifies how to deal with Task inputs and outputs
>    - e.g. sending selected outputs to other Tasks or specifying the
>    Report Channels that should be used to report results to Collectors.
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 11]
> 
>    Measurement Suppression information is used to over-ride the
>    Instruction Schedule and temporarily stop measurements or other Tasks
>    from running on 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.  It is also considered that it will be easier
>    for a human operator to implement a temporary explicit suppression
>    rather than having to move to a reduced Schedule and then roll-back
>    at a later time.
>
>    The explicit Suppression instruction message is able to simply
>    enable/disable all Instruction Tasks (that are enabled for default
>    suppression) as well as having fine control on which Tasks are
>    suppressed.  Suppression of both specified Task Configurations and
>    Measurement Schedules is supported.  Support for disabling specific
>    Task Configurations allows malfunctioning or mis-configured Tasks or
>    Task Configurations that have an impact on a particular part of the
>    network infrastructure (e.g., a particular Measurement Peer) to be
>    targetted.  Support for disabling specific Schedules allows for
>    particularly heavy cycles or sets of less essential Measurement Tasks
>    to be suppressed quickly and effectively.  Note that Suppression has
>    no effect on either Controller Tasks or Controller Schedules.
>
>    When no tasks or schedules are explicitly listed, all Instruction
Tasks or Schedules.
That's a generic comment on the draft. Be consistent with capitalization
> tasks will be suppressed (or not) as indicated by the suppress-by-
>    default flag in the Task Configuration.  If tasks or schedules are
>    listed explicitly then only these listed tasks or schedules will be
>    suppressed regardless of the suppress-by-default flag.  If both
>    individual tasks and individual schedules are listed then the union
>    of these options is considered - i.e. the listed shcedules plus the
>    listed tasks where present in other schedules.
>
>    Suppression stops new Tasks from executing.  In addtion, the
>    Suppression information also supports an additional Boolean that is
>    used to select whether on-going tasks are also to be terminated.
>
>    Unsuppression is achieved through either overwriting the Measurement
>    Suppression information (e.g. changing 'enabled' to False) or through
>    the use of an End time such that the Measurement Suppression will no
>    longer be in effect beyond this time.  The datetime format used for
>    all elements in the information model (e.g. the suppression start and
>    end dates) MUST conform to RFC 3339 [RFC3339] and ISO8601.
>
>    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
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 12]
> 
>    and the set of Task Configurations will be relatively static. The
>    Instruction 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 Suppression command without removing the existing
>    Instruction Schedules that would continue to apply after the
>    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 Task Configurations and Reporting
>    Channels to help ensure consistency and reduce errors.
>
>    Definition of the information model elements:
>
> // Instruction to the MA to configure Tasks, Channels, Schedules and 
> Suppression
>
> object {
>     ma-task-obj         ma-instruction-tasks<0..*>;
>     ma-channel-obj      ma-report-channels<0..*>;
>     ma-schedule-obj     ma-instruction-schedules<0..*>;
>     ma-suppression-obj  ma-suppression;
> } ma-instruction-obj;
>
> // Suppression object to temporarily override new task execution in 
> Instructions and optionally stop currently running tasks
>
> object {
>     boolean             ma-suppression-enabled;
>    [boolean             ma-suppression-stop-ongoing-tasks;] // 
> default: false
>    [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;
>
> 3.5.  Logging Information
 From what I can read in the framework, the logging information is 
always sent to the Controller.
Is that always what we want? Maybe the operational category 2 and 3 
logging information (and potentially the configuration information in 
category 1) should be sent to a syslog server.
 From my quick IM read, this is a limitation. Is this what you want?

>
>    The MA may report on the success or failure of Configuration or
>    Instruction communications from the Controller.  In addition further
>    operational logs may be produced during the operation of the MA and
>    updates to capabilities may also be reported.  Reporting this
>    information is achieved simply and flexibly in exactly the same
>    manner as any other Task.  We make no distinction between a
>    Measurement Task conducting an active or passive network measurement
>    and one which solely retrieves static or dynamic information from the
>    MA such as capabilities or logging information.  One or more logging
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 13]
> 
>    tasks can be programmed or configured to capture subsets of the
>    Logging Information.  These logging tasks are then executed by
>    Schedules which also specify that the resultant data is to be
>    transferred over the Controller Channels.
>
>    The type of Logging Information will fall into three different
>    categories:
>
>    1.  Success/failure/warning messages in response to information
>        updates from the Controller.  Failure messages could be produced
>        due to some inability to receive or parse the Controller
>        communication, or if the MA is not able to act as instructed.
>        For example:
>
>        *  "Measurement Schedules updated OK"
>
>        *  "Unable to parse JSON"
>
>        *  "Missing mandatory element: Measurement Timing"
>
>        *  "'Start' does not conform to schema - expected datetime"
>
>        *  "Date specified is in the past"
>
>        *  "'Hour' must be in the range 1..24"
>
>        *  "Schedule A refers to non-existent Measurement Task
>           Configuration"
>
>        *  "Measurement Task Configuration X registry entry Y not found"
>
>        *  "Updated Measurement Task Configurations do not include M used
>           by Measurement Schedule N"
>
>    2.  Operational updates from the MA.  For example:
>
>        *  "Out of memory: cannot record result"
>
>        *  "Collector 'collector.example.com' not responding"
>
>        *  "Unexpected restart"
>
>        *  "Suppression timeout"
>
>        *  "Failed to execute Measurement Task Configuration H"
>
>    3.  Status updates from the MA.  For example:
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 14]
> 
>        *  "Interface added: eth3 "
>
>        *  "Supported measurements updated"
>
>        *  "New IP address on eth0: xxx.xxx.xxx.xxx"
>
>    This Information Model document does not detail the precise format of
>    logging information since it is to a large extent protocol and MA
>    specific.  However, some common information can be identified.
>
>    MA Logging information model elements:
>
>    // Logging object
>
>    object {
>        uuid                ma-log-agent-id;
>        datetime            ma-log-event-time;
>        code                ma-log-code;
>        string              ma-log-description;
>    } ma-log-obj;
>
> 3.6.  Capability and Status Information
>
>    The MA will hold Capability Information that can be retrieved by a
>    Controller.  Capabilities include the interface details available to
>    Measurement Tasks and Channels as well as the set of Measurement
>    Tasks/Roles that are actually installed or available on the MA.
>    Status information includes the times that operations were last
>    performed such as contacting the Controller or producing Reports.
>
>    MA Status information model elements:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 15]
> 
>    // Main MA Status information object
>
>    object {
>        uuid                ma-agent-id;
>        urn                 ma-device-id;
>        string              ma-hardware;
>        string              ma-firmware;
>        string              ma-version;
>        ma-interface-obj    ma-interfaces<0..*>;
>
>        datetime            ma-last-measurement;
>        datetime            ma-last-report;
>        datetime            ma-last-instruction;
>        datetime            ma-last-configuration;
>
>        [ma-condition-obj    ma-conditions<0..*>;]
>
>        ma-task-capability-obj   ma-supported-tasks<0..*>;
>    } ma-status-obj;
>
>    // Additional status conditions
>
>    object {
>      string                ma-condition-code;
>      string                ma-condition-text;
>    } ma-condition-obj
>
>
>    // Interface information
>
>    object {
>        string              ma-interface-name;
>        string              ma-interface-type;
>       [int                 ma-interface-speed;]  // bps
>       [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;
>
>    // Supported tasks/roles
>
>    object {
>        string              ma-task-name;
>        uri                 ma-task-registry;
>        string              ma-task-role;
>    } ma-task-capability-obj;
>
>
>
>
> Burbridge, et al.       Expires February 21, 2015 [Page 16]
> 
This is where I arrived.
I'll stop here and review the next draft version.

Regards, Benoit

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Sep 2014 12:41:16 +0100

Hi Benoit,
on just one question:
Logging always goes to the Collector, right?
According to LMAP framework document Logging goes over Control, not Report
Channel:

   Control Channel: A Channel between a Controller and a MA over which
   Instruction Messages and Capabilities, Failure and Logging
   Information are sent.

Regards,

Greg

On Sun, Sep 14, 2014 at 11:38 PM, Benoit Claise <[email-masked]> wrote:

> tomorrow, here is some more feedback. I haven't had the time to review it
> all, so here is part 1.
> Both the framework and the information model say: Large-Scale Measurement
> Platforms (LMAP)
>
>
> Abstract
>
> It's only later (section 3.3) that I understood that the Controller could
> be changed.
>                                                       |---------->
> Channels
> Both active and passive measurements are in scope, although there may be
> differences in their applicability to specific use cases, or in the
> security measures needed according to the threats specific to each
> measurement category
>
>
>
>    2.  Data Transfer Tasks
>
>        A.  Reporting Tasks report the results *of *Measurement Tasks to
>            Collectors
>
>
> // MA pre-configuration minimal information to communicate initially with
> Controller
>
> object {
>     [uuid                ma-agent-id;]
> "The choice of Controller", do you want to say "an alternate Controller",
> because at this point the MA is already in contact with the Controller.
>
> details for
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>
>

---

From: <[email-masked]>
Date: Thu, 18 Sep 2014 10:40:58 +0100

Hi,

I think the text Benoit was commenting on is:
<<   2.  Channels.  A set of Channel objects are used to communicate with
       a number of endpoints (i.e. the Controller and Collectors).
Benoit is right that this could be written better. Perhaps simply quote the definition from the framework:
Channel: A bi-directional logical connection that is defined by a
   specific Controller and MA, or Collector and MA, plus associated
   security.

Greg – yes. Reports (of measurements) go to the collector. Logging information – info about the operation of the MA that may be useful for debugging – goes to the Controller.

Best wishes
phil

From: lmap [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 17 September 2014 12:41
To: Benoit Claise
Cc: [email-masked]
Subject: Re: [lmap] Feedback on draft-ietf-lmap-information-model

Hi Benoit,
on just one question:
Logging always goes to the Collector, right?
According to LMAP framework document Logging goes over Control, not Report Channel:

   Information are sent.

Regards,

Greg

On Sun, Sep 14, 2014 at 11:38 PM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Since we will be spending time on draft-ietf-lmap-information-model tomorrow, here is some more feedback. I haven't had the time to review it all, so here is part 1.

     Information Model for Large-Scale Measurement Platforms (LMAP)
                  draft-ietf-lmap-information-model-02
What does LMAP stand for?
In the use cases draft, it says "Large-scale Measurement of Broadband Performance (LMAP)"
Both the framework and the information model say: Large-Scale Measurement Platforms (LMAP)

Abstract

Requirements Language

Status of This Memo

Copyright Notice

Table of Contents

1.  Introduction

It's only later (section 3.3) that I understood that the Controller could be changed.

2.  Notation

   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].
Should the framework be normative? I believe so, specifically when I see all those Capitalized terms that are only defined in the framework.
This leads to another point. You miss a terminology section because some terms are specific to this document. Example: Task Suppression.

As such, some subsets

   It should also be noted that the MA may be in communication with
The "MA" or the "MA device"?
I'm asking because the rest of the sentence speaks about "configuring", and we said that MA can only be configured by one and only one Controller.

"such systemS" ... "enabling/disabling the measurement functionality of the MA."

Each

          Schedule
              |----------> Timing
                                   |----------> (Task Channels and downstream Tasks)

   1.  Measurement Tasks

Why not traffic?
From the charter:
Both active and passive measurements are in scope, although there may be differences in their applicability to specific use cases, or in the security measures needed according to the threats specific to each measurement category

   2.  Data Transfer Tasks

       A.  Reporting Tasks report the results or Measurement Tasks to
           Collectors
"Reporting Tasks report Measurement Tasks to Collectors"
Really? So the Controller configures the Reporting Tasks on the MA, and the MA reports them to the Collector?

Maybe you meant?
       A.  Reporting Tasks report the results of Measurement Tasks to
           Collectors

       to participate as an MA.
So the pre-configuration information is only for the Controller communication (I guess so) or also for the collector and measurement peers?

The pre-configuration

The

// MA pre-configuration minimal information to communicate initially with Controller

object {
    [uuid                ma-agent-id;]

   During registration or at any later point at which the MA contacts
   the Controller (or vice-versa), the choice of Controller,
"The choice of Controller", do you want to say "an alternate Controller", because at this point the MA is already in contact with the Controller.

details for

Some

   // MA Configuration

   object {
       uuid                ma-agent-id;

That's where I arrived.

Regards, Benoit

_______________________________________________
lmap mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lmap