All
Review of TR-547 1.1: Wed 28, 10:00-12:00 pm CEsT (and tentatively also 29 and 30)
- Invited Ramon, Nigel, Ronald, Pedro, Arturo. Please others interested to contact Andrea.
TAPI weeky call
Karthik Sethuraman informs that ONAP side are looking at TAPI for topology model, it it worth that TAPI team tries to attend ONAP.
- Shown diagram from https://wiki.onap.org/display/DW/Proposed+Topology+IM+Sketch, where "The topology model is inspired by TAPI."
Nigel Davis informs that O-RAN specifications are centered on Papyrus/UML and they are considering Eagle tool for the automatic translation to Yang.
- O-RAN folks attended last IISOMI call, see 2021-07-23 IISOMI Meeting notes
- Apparently some resources may be available to progress on the uml2yang tool.
Technical discussion on Integration of Streaming and Fault Management
Andrea Mazzini presents current state of TapiNotification, TapiStreaming and TapiFM models.
Agreed a simplification, only one object, ObjectNotification, augments the new EventNotification, which is replacing the old Notification signal:
- Confirmed that for TAPI 2.3 the "object creation" model will still be different for Notification and Streaming.
- Agreed that backward compatibility is assured by keeping the "deprecated" Notification signal.
- Agreed to explore a more generic data type than name-value pair (which seems less interoperable) for the new object creation notification - this to allow any dump of contents, possibly aligned to Streaming augmentations (see diagram below).
- Post meeting note, leaving the UML type as "undefined", the uml2yang translates to Yang:
leaf-list object-content {
type string;
description "The object content, e.g. all the attributes of a newly created object. The mapping is not specified.";- Preliminary agreement that TAPI 2.4 object notification will fully align to Streaming augments:
- Ramon Casellas indicates the JSON Patch (RFC 6902), which is a list of changes:
A JSON Patch document is a JSON [RFC4627] document that represents an array of objects. Each object represents a single operation to be applied to the target JSON document. The following is an example JSON Patch document, transferred in an HTTP PATCH request: PATCH /my/data HTTP/1.1 Host: example.org Content-Length: 326 Content-Type: application/json-patch+json If-Match: "abc123" [ { "op": "test", "path": "/a/b/c", "value": "foo" }, { "op": "remove", "path": "/a/b/c" }, { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, { "op": "replace", "path": "/a/b/c", "value": 42 }, { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } ]
- Ramon Casellas suggests the "anydata" (RFC 7950) for the object content:
7.10. The "anydata" Statement
The "anydata" statement defines an interior node in the schema tree.
It takes one argument, which is an identifier, followed by a block of
substatements that holds detailed anydata information.
The "anydata" statement is used to represent an unknown set of nodes
that can be modeled with YANG, except anyxml, but for which the data
model is not known at module design time. It is possible, though not
required, for the data model for anydata content to become known
through protocol signaling or other means that are outside the scope
of this document.
An example of where anydata can be useful is a list of received
notifications where the specific notifications are not known at
design time.