- TR-543 v1.0-info UML-OpenAPI Mapping Guidelines
- Kam reported that the document has been sent to Cassandra for posting on https://www.opennetworking.org/software-defined-standards/models-apis/.
- Kam noted that due to IISOMI IPR/Licience/Copyright concerns, TR-543 will stay as a ONF document and will not be a shell document like TR-514, TR-515, and TR-531.
- Currently TR-514 (UML Modeling Guidelines) is a shell document pointing to IISOMI-514 for the guidelines. Will revise TR-514 so that it is a self-content document and no need to point to IISOMI-514. Similarly revise TR-515 and TR-531.
- TR-544 v1.0-info UML-ProtoBuf Mapping Guidelines
- So far no feedback from ONOS.
- The meeting agreed to go ahead to publish TR-544 without waiting for ONOS feedback.
- Action item - Kam/Nigel: Submit the document to Cassandra and Timon for publishing
- London March 12-16 F2F meeting: Face-to-Face Meetings
- 11-15 June 2018 F2F meeting:
- Darmstadt, Germany, hosted by DT
- Action item - Kam/Nigel: Set up new doodle poll
- Invitation to 6-10 August 2018 ITU-T Q14/15 Stockholm meeting
- 2019 Meeting Plan: Tentative plan. Need hosts
- 1Q in China
- 2/3 Q in Canada
- 4Q (before Christmas) in Europe
- DONE: The purple color for non-physical layer was modified.
- DONE: The section 4.4 was deleted.
| ||Control model||Chris|
- Chris described what he has updated to the slide pack of last week
- Added the ControlConstructControlsConstraintDomain association
Noted that to keep the diagrams simple, use PC to represent all of the functions PC, LTP, FC, FD, SoftwareProcess …
- Explained why not to have a Control Domain (the ControlSystemView) class
- To avoid unnecessary duplication of the existing association among the ConstriantDomain & PC, LTP, FC, etc.
- Add the NE boundary in the diagram aiming to help people to relate the new model construct (concept) to their traditional/ingrained NE concept.
- Rename Control Component to ControlConstruct
- Action item - Chris: To post the updated slide deck.
- Karthik reported that they are working on TAPI 2.0.1 release and on the Termination point model
| ||Wireless Transport||Martin|
- Martin reported that Thostern is proposing a TR for Device Management Interface Definition (DMID)
- Martin reported that the WT 5th POC will base on the TR-512 v1.3.1 Core model
- Karthik asked Martin the purpose of the WT OTN YANG in Centenial.
- Martin explained that the WT OTN YANG is temporary to address the problem of WT taking the TAPI YANG into OpenDaylight, specically regarding the -g for signifying grouping
- Karthik: The TAPI YANG has no problem;
- Martin will look at the TAPI SNOWMASS YANG
- Martin and Karthik will talk off-line at the London meeting
| ||Compatibility|| |
Discussion on compatibility issues:
- Many aspects of compatibility: Tooling, model profile, model, model artifact lifecycle, YANG, schema, codes,
- Methods to address compatibility issues: versioning, profiling, transformation statement/model,
- Need to make indication/signature of the version visible
- Need clear indicationof the environment
- Recognize there is sliding scale of compatibility
- Model changes: labe/name, structure, semantics/behaviour, ...
- Is there indication in UML regarding model artifact (e.g., class, attribute, operation, ...) transformation
- Action item - all: to explore what existing techniques in the sofeware community, in UML, ...
|IM-F||TR-512 v1.4 topics||Chris/Nigel|
- Control model, Processing Construct, and Operation Pattern
- Nigel walked through the updates to the model
| ||V1.4 Status/Progress||All|
- Status of the v1.4 items were checked.
- All confirmed, except item #6 Resilience is yet to be confirmed by Karthik
- Action item - To-be-removed: Please confirm whether item 6 Resilience will be on schedule for v1.4 or not.
| || ||Nigel|
- ForwardingEntity Pac Usage:
- Not discussed. Running out of time. Defer to next week.