| IM-D | TR-512 v1.4.1 |
| - Progress of v1.4.1
- Done with .2 (checked), .6 (checked); progressing on .3 (aim to finish in couple days)
- Nigel welcome help in doing the work (send Nigel email),
- Need to make sure using the exact same version of Papyrus, stereotype, style sheet, and profiles,
- Test out with a single diagram first, screen resolution won't be a concern;
- Ask Chris if he has a good monitor for the Sydney meeting, so that can see the diagrams better
- Issue raised in the call of last week
- Not displaying the association end Modifier of the attribute (no more a button to press to display).
- Scott Mansfield Action Item: to feedback to the Papyrus development community.
|
| TAPI Equipment model |
| - Core euqipment model pruning and refactoring for TAPI
- Nigel has pruned out un-needed stuff, re-structured,
- Aim to review in the next TAPI call to make the content and structure are right
- Class vs Data type
- Karthik: Need clear definition/clarification on the difference between Class and Datatype,
- Need guideline on using one or the other
- Not about tooling
- Data type: two opinions
- (1) No instance (cannot be referenced), complex data structure of the value of the attribute;
- (2) All the attributes in the data type (substructure) have values, thus together counted as a key (i.e., identified by the values of the whole substructure, and thus equivalent to a key). In YANG every data substructure needs a key to refer to (thus makes it looks like (no differnce from) a class instance)
- Will have discussion in IISOMI call
|
| Streaming approach |
| - Nigel has worked through the approach of compaction/retention of the stream of events (alarm etc) to make sure that the two parameters (compaction and retention) are correct.
- To maximize capturing the history and also be consistent with the current states,
- Exposing the stream across the systems
|
| Profile |
| - Thorsten raised the need of profile in the Wireless Transport model/interface
- From past experience, profile and template can be complicate
- Thorsten's requirement is quite stright forward, less complex, need reference from LTP to the profile, doesn't need value range, etc.
- Need to be aware that complexity may appear down the line
- Profile: a class with an identifier so that it can be referenced
- Aim to have the profile model in the v1.4.1 time frame. a class with an identifier so that can be referenced,
- TAPI uses profile too, it has uuid and name, in TAPI common; can profile every class,
- Overwrite of attributes in the profile, modification of attributes in the profile instance
|
| | Virtual Network | | - Virtual Network from a Core perspective
|
| Sydney meeting |
| - For information, not discussed
|
