In general we need to focus on agreement and actions :
4/13 Day 1
4/15 Day 2
4/16 Day 3
4/17 Day 4
6:00 - 6:50 EDT
|Admin, welcome, 2020 Work Plan||Ethernet Examples|
7:00 - 7:50 EDT
|Discuss approaches for Equipment||Security|
8:00 - 8.50 EDT
Assigned to Slot
a or b for 1/2 slot
|Topic Title||Lead||Length requested|
(full or 1/2 slot)
|Topic Description||Meeting Notes |
with Document Links
and action items
|1.1||KL||60 mins||Bubble chart slide showing work items and their relationship / planned order|
Note: Moved from 2.1a as this feeds into View Context (ND)
Agreed to use the spec approach.
Not to specialize ControlConstruct for streaming.
Agreed that in this release, we assume reliable streaming. Not address unreliable broadcast case
There are prior work in TMF that we may gain benefit on (Spec alternatives / requires / excludes / refinement (substitution, division, fusion))
Actions moved to Task 65 - Streaming
3 things (types of activity/performer): Exposing (reporter), mapping (mapper), setting up of mapping (mapping creator. It is driven by the intent)
Separate namespaces for server context, local context, client context
What represents computation capability? PC? CASC? else? Use Spec approach,
Representation of Library of Spec ?
What do we do with the actual calculation? Who own the view (ExposureContext - EC)?
In the Spec: View change. Deep control (e.g., packet counts) that causes view change.
The Spec defines the capability, e.g., spot light, flash light, to activate/deactivate,
Actions moved to Task 11 - View/Context
Note: Moved from 1.3b as this flows better with View/Context and Streaming
Note: Moved from 1.3.a to 2.1.a
Work flow of Task (T57)
Aim for extending TAPI.
|2.1.b||ND||30 mins||T56 vs T37|
Note: Moved from 1.3a
Note: Moved from 1.3.b to 2.1.b
In TAPI, the photonic layer FC spec is very complex. It need to be understandable by a smart controller.
Pursuing Simplified spec model for TAPI usage, including LTP Sped and FcSpec. It will then be taken to augment the TAPI model.
Agreed with the proposal (slide #5)
Actions moved to Task 56 - Simplified Spec Model
|2.2||ND, KL||60 mins||Strategy of approach|
Once identify a property (e.g., temperature), then decorate it at specifc level of the equipment decomposition (e.g., at the CPU of the equipment).
Consider have a dot A document (.A.-)
General model of property or just focus on physical equipment property.
|2.3||ND||30 mins||Close off on strategies|
Note: Moved from 1.2a as this fits better with Constraint Domain Split (ND)
Note: Moved from 2.1.a to 2.3.a
Tooling is more than just uml2yang, but implementation forms, including injecting identifier, etc.,
|3.1||KL||60 mins||Need to look at IEEE, ITU-T, TAPI and OIMT aspects|
Clarified that PoE injection/extraction at Access Port: This is just on the Physical layer (to the left)
|3.2||JS||60 mins||Authorization/Access Control|
Task: Extend the Core (party, task/job) with addition attribute for security policy.
Decision of N-ACM vs XACML is a separate question.
Application: Apply this framework for virtual network operation (configuration).
Note: Moved from 2.3 to 3.3
Temporality - changes
This is related to security.
|4.1.a||ND||30 mins||Update on practicality of this - does it solve the problem ?|
Update strategy - agree to move forward to it ?
Note: Moved from 2.1.b to 2.3.b
Note: Moved from 2.3.b
Note: Moved from 3.3.b
CDB defines a boundary
CRSP enforces the boundary
|4.1.b||KL||60 mins||Re-visit Bubble chart slide showing work items and their relationship / planned order|
Note: Moved from 3.3 to Friday 4.1
Packaging, association navigability changes