Streaming: connection-protocol and encoding-format combinations

[roshan-joyce-fujitsu]

Please see the following tree:

 augment /tapi-common:context:
    +--rw stream-context {tapi-streaming}?
       +--ro available-stream* [uuid]
       |  +--ro connection-address*      string
       |  +--ro stream-state?            stream-state
       |  +--ro supported-stream-type
       |  |  +--ro supported-stream-type-uuid?   -> /tapi-common:context/tapi-streaming:stream-context/supported-stream-type/uuid
       |  +--ro stream-id?               string
       |  +--ro connection-protocol?     connection-protocol
       |  +--ro uuid                     uuid
       |  +--ro name* [value-name]
       |     +--ro value-name    string
       |     +--ro value?        string
       +--ro supported-stream-type* [uuid]
          +--ro stream-type-name?              string
          +--ro record-retention?              string
          +--ro segment-size?                  string
          +--ro stream-type-content*           tapi-common:object-type
          +--ro log-storage-strategy?          log-storage-strategy
          +--ro log-record-strategy?           log-record-strategy
          +--ro record-trigger?                record-trigger
          +--ro uuid                           uuid
          +--ro name* [value-name]
          |  +--ro value-name    string
          |  +--ro value?        string
          +--rw compacted-log-details {tapi-streaming}?
          |  +--ro tombstone-retention?              string
          |  +--ro compaction-delay?                 string
          |  +--ro max-allowed-segment-roll-delay?   string
          |  +--ro max-compaction-lag?               string
          +--ro connection-protocol-details {tapi-streaming}?
          |  +--ro allowed-connection-protocols*   connection-protocol
          |  +--ro encoding-format?                encoding-format
          +--ro information-record-strategy {tapi-streaming}?
             +--ro record-suppression?                      record-suppression
             +--ro value-expectation?                       value-expectation
             +--ro allowed-dither-from-value-expectation?   value-expectation-dither

Inside supported-stream-type object, shouldn't connection-protocol-details be a list? And each entry in that list can specify a protocol and the encoding-format.

As of now, if the provider wants to restrict one format (say, protobuf) for a specific protocol only (say, GNMI), there is no way to do that.

Also, shouldn't the available-stream object also specify the encoding-format in addition to the connection-protocol?

[nigel-r-davis]

The provider can advertise as many supported-stream-types as is necessary to represent the combination of data sets, protocol details and encoding formats that it offers. The supported-stream-type list deals with the various combinations. The assumption here is that if a data set is provided via various alternative formats, then there will be multiple supported-stream-types.

If the provider supports a specific set of data over a stream that is protobuf over GNMI it would specific a supported-stream-type with only that combination (i.e., a single allowed-connection-protocol of GNMI and a single encoding-format of protobuf). If it supports the same data over a GNMI stream that is not protobuf encoded but uses JSON, then this is specified via a separate supported-stream type. On this basis it could be argued that allowed-connection-protocol should not be a list as the supported-stream-type caters for all combinations.

The supported-stream-type can be used to provide a full unique combination of data set, protocol and encoding and on this basis the available-stream does not need to specify encoding-format.

I hope that makes enough sense. Would it be beneficial to add text to TR-548 to explain this?

[roshan-joyce-fujitsu]

Thanks @nigel-r-davis for the explanation. It makes sense to me. The downside is that each supported-stream-type entry will be repeating the same details in the other fields like compacted-log-details etc.

But I agree that with the explanation you provided, the scenario I mentioned is addressed without making any changes to the model. So, overall it would be better to add the explanation to TR-548 and leave the model intact.

[nigel-r-davis]

I agree that there will be more individual supported stream types in some cases, but it is expected that there will be very few combinations and hence no significant volume issue.

[nigel-r-davis]

I have added the following text to TR-548

3.7.1.1 Supported stream type combinations

The supported-stream-type structure allows a stream to be fully defined and can be used to provide a full unique combination of data set (stream-type-content), protocol and encoding. It is expected at this stage that each structure defines one unique stream fully specifying all individual property. It is recommended that the allowed connection protocol field has only one entry for each supported-stream-type. The stream type will then specify a single explicit encoding format and connection protocol combination for the connection protocol details. The provider can advertise as many supported-stream-types as is necessary to represent the combination of data sets, protocol details and encoding formats that it offers. The supported-stream-type list deals with the various combinations. If a data set is provided via various alternative formats, then there will be multiple supported-stream-types, each one defining a single specific format. An available-stream (see below) can then reference a supported-stream-type with no ambiguity and the available-stream need not define the connection-protocol. For example, if the provider supports a specific set of data over a stream that is PROTOBUF over GNMI it would specific a supported-stream-type with only that combination (i.e., a single allowed-connection-protocol of GNMI and a single encoding-format of PROTOBUF). If it supports the same data over a GNMI stream that is not PROTOBUF encoded but uses JSON, then this is specified via a separate supported-stream-type.

[nigel-r-davis]

I believe all is clear now. I will close the issue. If you feel that we need to do more, please reopen.