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?