Minutes for LMAP at interim-2014-lmap-1
minutes-interim-2014-lmap-1-1

LMAP Interim Meeting

IETF rules apply

WG Status - Use cases submitted - AD comments 
 - Framework through WGLC

Use case comments - AD Review
all but one addressed by Phil Eardley.
Need Reference to RFC 7258 "pervasive monitoring is an attack"

Framework AD preliminary comments - 
Scope mentions that IPPM work is out of scope, but we also want 
passive monitoring metric development should be described as out-of-scope.
marcelo asks to provide some pointers, perhaps some text.
IPFIX has information models, other trappings of
YANG - model is already present for passive, but not for active,
and this could be mentioned.
But take care of this comment at AD-review - draft moves forward.

================================

IM presentation - Trevor
Purpose of the IM

Define a task.. Schedule, then do queues go in the middle


-Timing
  no calendar defaults
  no negative enumerates 
  no end of month offsets

  We already have "immediate" -   
  we have set time (offset) from immediate
  Startup task only on MA re-start
  Parallel tasks in schedule will run in parallel, unless MA 
implementation prevents it.

Discussion:
Data persistence can be revealed from the Instruction number.
"Last Instruction Received" must match.
Remove JSON

Do we need to standardize Condition Codes?  Not clear, 
pick up tomorrow. do we have a set, or structure of codes?


Overview of the IM/different sections of the IM
Changes in 02
-- added roles
-- still need t solve the issue of how one task sends information to
another task
Channels and Downstream tasks
- channel granularity:
  @juergen: provide flexibility; provide options in both task and schedule
  @tim: shall we do it one-way?
Juergen: In the YANG model, this is done differently. Tasks config is
more static, channel is just one more option
Tim: Downstream task is part of the schedule seems weird, would make
more sense that is part of the task definition
Ken: put it as part of the schedule and for downstream tasks
Dan: use another terminology like "next scheduled task"
??: destination task?
Juergen: include option in the scheduled task in order to have more
flexibility
....
Trevor: some people think we should leave as in 02 and some other people
think we should do it both (the scheduled task and the task config)
Greg: can reporting task be shared across multiple measurement tasks?
Trevor: yes
Trevor: I am happy to move the channel as a task option
Tim: Keep it simple, don’t give two ways of doing it, don’t have it in the
task config and in the scheduled
Ken: i think you must be able to define in the schedule, it may also be
in the task config
Trevor: no consensus in the room, how do we proceed?
Trevor: proposal: downstream task most people want to keep it in the
scheduled task and the channel to the task config level
Ken: reporting tasks are in the registry?
Trevor: measurement tasks are in the IANA registry, there is also a
private registry
Ken: I think management task should be defined in a public registry
Trevor: explicitly define data queue
Ken: the queue can be assumed to be properly dimensioned so we don’t
need parameters
Trevor: Memory as a capability
Benoit: provide all info relevant when there is an error
Phil: the queue is a helpful description, but you can implement it as
you like and if there is a problem report the error condition
Tim: if it is for clarity, i wouldn’t make it a formal element
Phil: i prefer that
Marcelo: +1
Ken: +1
Ken: if we do this, they should be ingress queues
charles cook: is is possible for a task in one ma be directed to a task
in another ma
Trevor: no
Benoit: i think the definition of the queue is going too far, if it helps
for explaining the text, go for it, but not include parameters
Trevor: I will informally mention the queue in the description and see
what people thinks

Task configs versus scheduled tasks
Ken: everything that is explicitly called in the scheduled task
overwrites the task config

Roles
Whatever the registry people goes for

Reporting:
Do we report the task config? Don’t include by default
What if the reporting task is suppressed? leave undefined

Timing:
we remove the defaults values and allow wildcards

Others:
JSON example, should we remove it? keep it for a while
Do we need to define error codes? (multiple codes use the same ones?)


- will reporting tasks be defined in metrics registry
  @marcelo: should be defined in the protocol specification
- queues b/w tasks and downstream-tasks:
  @trevor: do we need queue objects and queue parameters or protocol specific?
  @ken: don't parameterize a queue; log and report errors
  @juergen; explicitly mention a queue; parameterize it or not
  @benoit: hide queue-based details from non-implementors
  @benoit: probably we need an implementation guidelines
- what happens if reporting task is suppressed
  @ken: don't do anything


============================================================

New Yang Model

Uses RESTCONF - request to check this with the Netconf WG,
to see if this is a reasonable spec.

Author indicates that RESTCONF has good tools for validating
messages, but YANG is the important thing. Can convert between
JSON and YANG, primitive code.

How do we decide what to do here?  review all decks first.

Some proposals only work in PUSH model.
PUSH vs PULL is very critical to all devices behind the NAT/FW.
Default is that MA contacts the controller, and
otherwise there is a required persistent TCP connection
(which does not always work).

Need to have a pin-hole in the FW, Controller says to MA,
please query the Controller for new Instruction.
HOW the FW is left open for this Controller to MA comm.
is left to implementation.

==============================================================

Marcelo HTTP+JSON

TLS - There are concerns for running the many MA connections
at scale.

Data model has been updated to reflect info model 02
everyone agrees to do http & json (restconf from
question is whether to do yang
Mike B (on phone) - json might be easier (?)
Trevor - xml & json are ~ the same
Juergen - did yang data model. default way is to do xml. i-d how to do in json.
vaibhav - backend scripts to generate json from sql backend datbase schema
trevro - is yang or json schema easier?
Arne - idea of standardising json schema was turned down at ietf.
marcelo - naming slide
marcelo - comm slide
marcelo - control - use post not get
marcelo - report - use put or post? proably post, for same reasons as control using post
marcelo - data mode 
Vaibhav - imploementation. been working on json. next step is protocol on top.
Stephen - impact of tls, if many sessions in parallel
Marcelo - security analysis - usually tls + mutual auth. No performance analysis.
Trevor - SK latform uses. assume there;s nothing better.
Stepehn - if have to re-establish session, maybe have to use tickets for performance?

==============================================================

Protocol description from the Framework.
Phil/Al/Jason

MA could generate a temporary ID using an ID plus time
or conditions, this ID would only persist until the Controller
tasks the MA to generate a new ID. 

>>> but we currently have the MA getting it's ID from the Controller?