Child pages
  • 2022-09-01 OIMT Meeting notes

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Time

Item

Who

Notes


Admin

All

Actions

Action items completed

Action items discussed

Action items re-dated 

Re-dated according to the review plan. See the call plan below for the document review plan 


Streaming documentNigel

Nigel provided a quick overview of the changes.

  • Overview and positioning first
  • Basic structure of solution
  • Autonomous provision of information
  • The summary of the communication mechanism
  • The model
  • Controller Hierarchy diagram (color scheme the same as the model colors)
  • Overall stream lifecycle

Further cleaning of the end of the document required.

Nigel worked through detail explaining each section.

The primary focus is on the area in the red rectangle with significant coverage of the area in the green rectangle.

The description relates to a solution low down in the hierarchy (to simplify the explanation). It is not covering slicing as that happens higher up.

Nigel noted that there will need to be some harmonization with the slicing work.

The view mapping here is to clean up the model and presentation of all of the information to pass to the orchestrator.

Malcolm and Nigel agreed that the VMF is being used for different purposes in the two cases.

Nigel explained that the description related to a place in the solution where the are few permanently connected clients that expect live updates so as to maintain an ongoing view that is used to take control actions. Hence Streaming is vital.

<broke at this point to go to the TR-512.5 issue>

There is a general explanation of streaming in the "autonomous provision of information".

Summary of streaming characteristics still needs to be updated.

Nigel noted that he had added diagrams that explained the use of the earlier work on signals

The diagrams above highlight the signal and the get.

This is followed by the stream model. 

The diagrams now have a UML component to identify the client and provider as appropriate e.g., as below...

The document now includes data types as well as the classes.

Attributes have been added.

Comments have been added to the properties.

The attributes have been added.

  •  Nigel Davis Add data types column to class tables
  •  Nigel Davis Add lifecycle stereotypes
  •  Nigel Davis Agree whether the attributes should be directly in the classes in the streaming model or whether there should be augments (as in TAPI). We could potentially use text to clarify this.
  •  Nigel Davis Review property names to validate that they are appropriately general.

Nigel highlighted the provider stream classes.

Some classes are not fully populated with properties, we may wish to include properties in some of the new classes that do not have TAPI originated detail.

Nigel noted that conveyedInformation had no detail and needed to be investigated.

  •  Nigel Davis Investigate and correct or explain the conveyedInformation property.


  •  Nigel Davis Correct the ReceiverStreamBuffer to ReceiveStreamPipelineBuffer in gendoc script.

Nigel noted that he had tried to make some of the streams clearer.

Brief discussion on get approach considering the request construction and handling of the response which may go to the CC or straight into the view depending upon the specific get.

Nigel noted that the complete model is in Figure 6-8. Whist this is dense, it seems sensible to provide a view of the assembly of what has been discussed in earlier session.

Nigel then explained the following diagram

Note that the colour or the SD symbol will remain yellow as that essentially depicts data storage.

Nigel explained that the diagram to the right of the figure is a summary of a fragment of the controller hierarchy and the main diagram in the middle is a fragment of the fragment.

The text in the document explains the flow and this was summarized.

Nigel explained the overall pattern and noted that flow may be between CDP and VMF or between CPs (all external flows are between CPs). Some occurrences of the pattern do not have CP etc.

Information comes from the devices, gets stored in a nodal view, gets transformed into a network view and stored and then further transformed into an external view and stored before streaming etc.

The transformation could be from a proprietary model to TAPI between the controllers or to core etc.

Nigel pointed out that the text explains where the document is intentionally not describing some process of activity.

The sections 6.6.n will be converted into a numbered list.

  •  Nigel Davis Convert the descriptive text in the streaming section of TR-512.8 6.6.n into numbered lists.

The assumption in the sections is that the provider is set up first then the client queries and then connects. Clearly, the provider may add streams etc. as it progresses.

Nigel requested that Malcolm should review the next version of this document (once the sections converted to numbered lists etc.).

  •  Nigel Davis Deliver an updated version of TR-512.8 for team review of the streaming sections.
  •  Malcolm Betts Provide review comments on TR-512.8 streaming, especially focusing on the lifecycle of interaction of client and provider (in section on "Operation of the streams").

Malcolm emphasized that the document should not go into detail of specific mappings. Nigel agreed that that was not the intention.

Malcolm also emphasized that the scope of the information should not be defined. Nigel agreed.

Nigel noted that a .A. document could be used to explain the mappings.

Malcolm agreed that a .A. document should cover mapping and slicing examples (just a few). This does not depend in any way on streaming. Nigel agreed.

Nigel noted that we could use Core to TAPI as an example. An LTP maps to both a NEP and a CEP. A few examples could lead to a sufficient understanding of mapping.

Nigel noted that the streaming section essentially ties together all of the previous described bits of the document to explain how they assemble into a streaming solution.




  •  Nigel Davis Provide update on necessary changes to the model cover the missing parts

There is no other place in the model where it is represented.

Qilei emphasized that this needed.

Nigel noted that the property is marked in red on the diagram for no obvious reason.

The type is also <<Obsolete>>. 

The comment mentions "ProtectionGroup" which is clearly out of date.

Chris noted that there was an agreement to move preliminary on to mature after two releases.

Nigel agree that this should be done.

  •  Nigel Davis Hing-Kam Lam Meet to discuss moving properties on to mature from preliminary (and attempt to recover the agreement).

Nigel suggested that a global replace on the .uml could be used to do the correction.

Note that some properties may not move as they have been changed less than two releases ago.

May need to do a diff against the previous release.

Could use gendoc to extract a flat form of the model with just attribute names and stereotypes then do a compare.

0 minNext calls

Individual's vacation plan: MB (August 11-31; Sept 19-30), AM (August 15-19), KL (August 22-26; Sept 19-Oct 12) 

  • Meeting planning proposal (where each meeting will deal with the corresponding actions (with the date of the meeting)):
    •  
    •  
      • ControlTask document overview
    •  
      • Spec document draft overview
      • Equipment discussion/resolution and preparation for delivery of document
    •  
      • Validate progress and plan model and documentation development
        • Review all relevant minutes/action resolution and draft document progress against plan including
          • Streaming (T65)
          • Task (T57)
          • Temporal (T73)
          • Spec (T56)
          • OAM (T5)
          • Views/Context (11b)
          • Media multipoint addition to .A.4 (T77)
          • Equipment (T8a) (??)
          • Aggregate (T64b)
        • Consider progress on and plan for delivery of
          • Compute and storage (T36)
        • Construct detailed action plan for delivery on target date  
  • At each meeting we should check that we are on track for the planned items

Future calls agenda items for consideration

  • TIP/MUST papers (CH, ND)
  • Catalog / inventory storage application (CH, ND)
  • IETF work on physical inventory model (ND)
  • RBAC vs ABAC (June 2021 F2F meeting Tue 1.2 ) 
  • To recap the previous OIMT discussion on synchronization management IM (later call)
  • YANG augmenting 
  • Leo on location model

...