Minutes for LMAP at interim-2016-lmap-1

Meeting Minutes Large-Scale Measurement of Broadband Performance (lmap) WG
Title Minutes for LMAP at interim-2016-lmap-1
State Active
Other versions plain text
Last updated 2016-01-21

Meeting Minutes

LMAP WG Interim Meeting 01/12/2016

(notes by Holger Wiehen and Barbara Stark)


Dan Romascanu
Jason Weil
Jurgen Schoenwaelder
Al Morton
Barbara Stark
Alissa Cooper
Timothy Carey
Holger Wiehen
Greg Minsky
Phil Eardley



1) Opening
Dan - opening and agenda; 2 note takers are chosen (Barbara and Holger);

2) WG Status

Chairs slides:

Dan - states little progress in active wg items; draft-liu-lmap-rest (alternate
protocol proposal) expired without activity on the mailing list (Jurgen
confirmed that lack of activity); if authors of the alternate proposal would
like to pursue it they may do as comments to the WG I-D.

3) IPPM Metrics Registry

Slides from Al:

Al - summarizes work on 3 drafts relevant for LMAP (see Al Morton's slides);
method used by the IPPM wg is specification by example
(draft-morton-ippm-initial-registry) Al - IPv6 is not covered by current
proposed metrics; draft-morton-ippm-2330-stdform-typep intended to capture IPv6
(RFC 2330 Update); solution is update to IPPM framework and not single drafts;
still difficulties to extend IPv4 metrics to IPv6 (might touch registry); Dan -
questions the working group status? Al - consensus call is outstanding; good
reception; Al - details key points of draft-morton-ippm-2330-stdform-typep
relevant for LMAP (see Al Morton's slides)

4) LMAP Information Model

Slides from Jurgen:

Jurgen - presents 4 key issues regarding the relation of the LMAP information
model and the IPPM metrics registry (see Jurgen' slides) Tim - questions if the
'schedule' needs a 'stop parameter'; couldn't it be solved by the
'calendar-end' of the 'calendar' object already in the draft; Jurgen - makes a
correction to the LMAP 'parameter' object shown in the slides; the 'parameter'
is an element of the 'action', not the 'schedule' Tim - questions the diference
between 'options' and 'parameters' Jurgen - 'parameter' would be anything
specified machine-readable; Tim - why not solve simpler with a YANG identity;
Jurgen - YANG eco-sistem leans towards stronger formalization (with a proper
YANG data model); Tim - distinguishing between options & parameters will
produce duplication in the spec;

Dan - states that the suggested formal approach assumes that part of the
IPPM-registry will be expressed as YANG models; questions complexity imposed on
the IPPM wg; Jurgen - recalls that the IPPM group aims to keep efforts like
YANG model to metric authors; Tim - summarizes wg's message to industry: IPPM
prefers formal definition of tests (machine readable); but there is a less
formal fallback (registry only);

Al - assumes that many parameters that could be machine readable will be known
in advance as IPPM fixed parameters; those don't need a schema to be read and
understood by machines (as the developer codes them). Tim - even fixed
parameters need to be defined with rigor (for example dimensions), even being
only human readable Barbara - states that there are use cases for machine
readable fixed parameters; for example an implementer might control a private
registry, and a change in metric's values should be understood and applied
programmatically; Al - a change in fixed parameter value in the registry should
result in a new metric name, so the MA points to a new metric URL Barbara -
states that this would not allow to run one same implementation with different
parameters; key is to not equal "fixed parameter" with "hard coded parameter";

Tim and Jurgen retake the discussion on start/stop times for schedules;
Tim - states that we have start and stop on event objects; proposed is an
additional start and stop on schedule objects; Jurgen - clarifies that those
times deal with a different granularity; Tim - adds that regarding the granular
control, the start/stop of measurement traffic could be controlled by action

5) Next Steps
Dan - questions next steps
Jurgen - estimates end of January to update the information model; suggests to
give people time to think through his information model proposals; feedback
required (especially on slide 8); if endorsed would extend his work; Dan -
comments that additional examples for the information model would be helpful;
Dan - announces plans for IETF 95: 1x 2 hour session; key contributor remote;
discuss possible time slot An additional interim meeting before IETF 95 is
planned for the week's around 02/15/2015 or 02/22/2105;