Reduction of network-specific terminolgy/acronyms

[rartych]

CAMARA API design guidelines ( section 2.5) recommends to reduce the use of telco-specific terminolgy/acronyms in developer-facing APIs. Although DiffServ is not telco-specific but rather low-level network-specific, I propose to reconsider:

• the name of the endpoint : /dscp
• the name of the property: dscp:
• the values of the property:

description: DSCP information for QoS
          enum:
            - CS0
            - CS1
            - AF11
            - AF12
            - AF13
            - CS2
            - AF21
            - AF22
            - AF23
            - CS3
            - AF31
            - AF32
            - AF33
            - CS4
            - AF41
            - AF42
            - AF43
            - CS5
            - EF
            - CS6
            - CS7
            - MAX_ALLOWED
          example: CS0

For values of DSCP property IETF RFC 4594 recommendations can be used to guide API users which value is the most relevant to their application:

    ------------------------------------------------------------------
   |   Service     |  DSCP   |    DSCP     |       Application        |
   |  Class Name   |  Name   |    Value    |        Examples          |
   |===============+=========+=============+==========================|
   |Network Control|  CS6    |   110000    | Network routing          |
   |---------------+---------+-------------+--------------------------|
   | Telephony     |   EF    |   101110    | IP Telephony bearer      |
   |---------------+---------+-------------+--------------------------|
   |  Signaling    |  CS5    |   101000    | IP Telephony signaling   |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF41,AF42|100010,100100|   H.323/V2 video         |
   | Conferencing  |  AF43   |   100110    |  conferencing (adaptive) |
   |---------------+---------+-------------+--------------------------|
   |  Real-Time    |  CS4    |   100000    | Video conferencing and   |
   |  Interactive  |         |             | Interactive gaming       |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF31,AF32|011010,011100| Streaming video and      |
   | Streaming     |  AF33   |   011110    |   audio on demand        |
   |---------------+---------+-------------+--------------------------|
   |Broadcast Video|  CS3    |   011000    |Broadcast TV & live events|
   |---------------+---------+-------------+--------------------------|
   | Low-Latency   |AF21,AF22|010010,010100|Client/server transactions|
   |   Data        |  AF23   |   010110    | Web-based ordering       |
   |---------------+---------+-------------+--------------------------|
   |     OAM       |  CS2    |   010000    |         OAM&P            |
   |---------------+---------+-------------+--------------------------|
   |High-Throughput|AF11,AF12|001010,001100|  Store and forward       |
   |    Data       |  AF13   |   001110    |     applications         |
   |---------------+---------+-------------+--------------------------|
   |    Standard   | DF (CS0)|   000000    | Undifferentiated         |
   |               |         |             | applications             |
   |---------------+---------+-------------+--------------------------|
   | Low-Priority  |  CS1    |   001000    | Any flow that has no BW  |
   |     Data      |         |             | assurance                |
    ------------------------------------------------------------------

Please note that QoD subproject defines only 4 values of QosProfile

enum:
        - QOS_E
        - QOS_S
        - QOS_M
        - QOS_L
      description: |
        * `QOS_E` - Qualifier for enhanced communication profile
        * `QOS_S` - Qualifier for the requested QoS profile _S_
        * `QOS_M` - Qualifier for the requested QoS profile _M_
        * `QOS_L` - Qualifier for the requested QoS profile _L_

[jpengar]

@rartych Thank you for your feedback. We will look into it and get back to you.

[jpengar]

This issue is actually aligned with Commonalities issue #108 and PR #120. From TEF side it is being validated inernally with the technical and business teams and a solution aligned with RFC4594 is being considered.

[jpengar]

@rartych API proposal change to address this issue in PR https://github.com/camaraproject/HomeDevicesQoD/pull/25. Please have a look at it.

@bigludo7 It would be great to have your review as well.

[jpengar]

PR #25 has been MERGED after being approved. Closing this issue.

Thanks @rartych & @bigludo7 for your feedback.