[Rum] Zaheduzzaman Sarker's Discuss on draft-ietf-rum-rue-09: (with DISCUSS)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-rum-rue-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rum-rue/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

First of all thanks for working on this technology to make communication
available and easy for special human beings. (I have worked with them to
converter text to sign language in my bachelor hence had a special feeling
while reading this specification).

I understood from the email discussions on the TSVART review
(https://mailarchive.ietf.org/arch/msg/tsv-art/Z_Ne5au4rCHwcig8bospMcLyzTc/)
that in the system RUI is deployed, we will have gateway(s) with two legs - one
with WebRTC (client <--> gateway) and one with RUI client communicating with
RUI server (gateway <--> server). With this understanding I have some points
which I believe worth discussing.

  - WebRTC communication will be congestion and rate controlled. This will use
  RTCP feedbacks to make the rate control and congestion control happen in the
  WebRTC peers. On the WebRTC part of the leg, this RTCP feedbacks will be
  available according to the WebRTC specification. However, this specification
  does not discuss how those RTCP feedback will be converted from the RUI
  server to RUI client (i.e the gateway) direction and vice versa. This will
  require the gateway to have such conversion functions to actually work. what
  is the thinking here? has this been considered? as I am not sure how is the
  network looks like between the RUI client and RUI server, there might be the
  Internet connecting them hence need to have congestion controlled traffic.

  - Thanks to Bernard Aboba for a comprehensive TSVART review of this draft and
  I would like to bring some issues, identified in that review, here to make
  sure they are addressed-

    * clarification on the use of ICE
    * clarification on what is a WebRTC client, WebRTC server, gateway, RUI
    client and RUI server. I believe all four have been conceptually used in
    the specification without concretely defining their roles. for example - if
    server is mentioned it need to be distinguishable if it is WebRTC server or
    RUI server ( I noted that there are servers in this specification which are
    clearly understandable).