Time | Item | Who | Notes |
---|
IM-D | Admin | Kam/Nigel | v1.3 approval status - We were expecting a board meeting yesterday where we were to present the 1.3 model. The meeting did not happen.
- Kam/Nigel to explore, with Timon, how to get approval
- The model is publicly available via the wiki as pre-board approved
- Discussion on whether we should distribute the right version of Papyrus with the model
- Nigel noted a concern that we would be in danger of becoming a Papyrus distribution site for an out of date version of Papyrus
Face-to-face meeting logistic - CORD
- No Science Fair on Tuesday
- Nigel to coordinate presentation generation with Lyndon (whilst Kan and Karthik are out)
- Kam will prepare a rough agenda for the Monday, Tuesday, Thursday and Friday meetings. Nigel will then take this on Whilst Kam is out
- Kam will create a wiki page for contributions.
- London meeting
- Expectation is that we will hold the meeting in the Ciena building as it now appears that the building work will be completed before the end of November
- Scott is still exploring one other alternative but we suspect that that will not work
- Nigel will send logistic information when final decision made on where the meeting will be held
|
| v1.4 work items | Nigel/Kam | |
| | Chris | #4 Software: - Chris gave a high level overview of available possible input from the industry
- IETF RFC-2287 SYSAPPL-MIB
- TMF TR-225
- File System Model from
- Chris noted things we should consider:
- Chris asked
- Whether this is the right direction to pursue,
- Whether should he wait until the face-to-face meeting to progress further with the team
- Action item - Chris: to push further for an initial sketch to be used for face-to-face discussion
- Malcolm commented that all these seems good for traditional Software management, but how about software that programs a FPGA to support, e.g., LTP, FC, etc.
- Action item - Malcolm: to send email to Chris for additional consideration points
-
|
| | Xiang | #7 Layer examples - Not discussed due to running out of time. Move to the IM-F slot
|
| | Augie | #21/24 UML-TOSCA - Not discussed due to running out of time. Move to next Thursday IM-D
|
| | Others | Other items |
IM-E | WT Spec model | Martin/Nigel | Spec model sketch - Nigel provided an overview of a model sketch for the WT model (the Papyrus model is attached MwModel.zip)
- Got the WT model from the Centennial Github
- Martin noted that in which the Core model explanation part has been removed
- Created a spec in the Papyrus
- Follow the approach of TAPI Spec model
- Need v1.3 for using the stereotype from AirInterfaceSpec to LayerProtocol
- The AirInterfaceSpec branch models/replaces the MW_AirInterface_Pac of the current WT model
- AirInterfaceTerminationPac contains the AirInterfaceCapability, AirInterfaceStatus, and AirInterfaceConfiguration
- Martin confirmed that these are all termination properties
- Martin confirmed that the attribute _airInterfaceList is outdated
- Current/HistoryPerformance haven't not been done in the Core model yet
- PoolPac and PropertyPac are rule stuff
- The navigable pointer attribute _logicalterminationpoint
- adaptiveModulationIsAvai (Boolean)
- If not available, should the attribute appear at all?
- Appear or not appear both are valid approaches
- The spec model approach allows incremental upgrade opportunity of the resource without the need to delete and re-create the resource instnace
- Martin noted that the AirInterfaceCapability approach in the current WT model makes the same capability being duplicated in all the air interface instance of the LTP. The Spec approach will eliminate the duplication.
- Attribute radioSignalID currently needs to support either string or integer due to existing implementations. How to model this.
|
IM-F | v1.4 work items | Xiang | #7 Layer examples - Xiang presented the layer examples slide deck: onf2017.202.01_XY_layer examples
- Slide 2 is a list of cases suggested by Malcolm
- Slide 4:
- Case 1 and Case 2 are modeling alternatives in which some layers are collapsed, i.e., no layer protocol stacking difference in the equipment

- Comparing the layer stacks in slide 4 with Figure 7-1A/G.709 (shown in slide 20)

- It seems that the gray ODTU.x and OPU4 are simply the shim layer for mapping only. Slide 4 could be redrawn as follow (yet to be verified). Similarly for the other diagrams.

- Action Item - Malcolm and Xiang: to redraw the layer stack diagrams
- For the packet LTP cases (slides 12-16), the C/S/I-TAGs are channelization, not layers
- In slide 15, the B-TAG should be B-MAC
- Slide 16 was not reviewed due to running out of time.
|