Subject: [Rum] Martin Duke's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Tue, 07 Dec 2021 10:00:12 -0800

Martin Duke 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:
----------------------------------------------------------------------

Thanks to Bernard Adoba for the TSVART review. It largely informs my DISCUSS.

1. If I understand correctly, this draft is not at all about interoperating
with a WebRTC endpoint, instead borrowing some requirements from that family of
specs rather than re-inventing the wheel. That's great, but putting that
explicitly in the intro would be helpful.

2. In particular, the statement that RUE is a "non-browser endpoint" is
confusing if it's not actually meant to interoperate with WebRTC. I *think*
you're attempting to distinguish between WebRTC's browser-only requirements and
endpoint requirements, but I could be wrong here.

3. In Section 5.5, you require conformance with RFC8835 with a few vaguely
worded exceptions. It would be helpful to actually go through that document
enumerate exactly which normative statements in 8835 do not apply. That said,
I'm not sure I agree with Bernard that 8835 requires *use* of ICE, rather than
support, but maybe we can clarify this in the TSVART thread.

4. As Bernard points out, this ambiguity extends to IPv4 and 6 support. The
8835 requirements are specific to browsers, so they might not apply. If you
require support for both, but not necessarily on the same device, it would be
good to say so.

5. In Sec. 6, it says "This specification adopts the media specifications for
WebRTC ([RFC8825])." Is this a normative statement? Must RUEs comply with the
entirety of that document, or is this an informative statement and the real
requirements are in the subsections of Sec 6? From the discussion, it sounds
like you want to include the requirements for WebRTC "endpoints", but not for
WebRTC "browsers". It would help to clarify all this.

It's also possible that my initial understanding is incorrect, in which case
the later points don't make any sense and some explanatory text is needed.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work to make the internet more accessible for all.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 23 Dec 2021 15:14:18 -0500

Thank you for your comments.  Please see inline

> On Dec 7, 2021, at 1:00 PM, Martin Duke via Datatracker <[email-masked]> wrote:
> 
Not quite.  I propose the following additional information in the media section where WebRTC specs are discussed:
To use WebRTC with this document, a gateway that presents a WebRTC server interface towards a browser, and a RUE client interface towards a provider is assumed.  The gateway would interwork signaling, and as noted below, interwork at least any real time text media, in order to allow a standard browser baed WebRTC client to be a VRS client.  The combination of the browser client and the gateway would be a RUE user.
> endpoint requirements, but I could be wrong here.
See above, but I still may have to just remove that “non browser endpoint” text, because it’s confusing people.

> support, but maybe we can clarify this in the TSVART thread.
The only reference to 8835 reads:
Implementations MUST conform to [RFC8835] except for its guidance on the WebRTC data channel, which this specification does not use. 

I have looked carefully at all mentions of “data channel” in 8835 and it seems really obvious what does and doesn’t apply.  Here is an example:

   For data transport over the WebRTC data channel [RFC8831 <https://datatracker.ietf.org/doc/html/rfc8831>], WebRTC
   endpoints MUST support SCTP over DTLS over ICE.  This encapsulation
   is specified in [RFC8261 <https://datatracker.ietf.org/doc/html/rfc8261>].  Negotiation of this transport in the
   Session Description Protocol (SDP) is defined in [RFC8841 <https://datatracker.ietf.org/doc/html/rfc8841>].  The SCTP
   extension for I-DATA [RFC8260 <https://datatracker.ietf.org/doc/html/rfc8260>] MUST be supported.

   The setup protocol for WebRTC data channels described in [RFC8832 <https://datatracker.ietf.org/doc/html/rfc8832>]
   MUST be supported.

None of it applies.  It might not be quite as obvious that because the above doesn’t apply, there is no SCTP requirement, but do you think we need to say that, given that the only discussion of SCTP is in relation to the data channel?
I could call out each one of the data channel statements, but it really does seem superfluous.  
> require support for both, but not necessarily on the same device, it would be

We require support for IPv4 and IPv6 expressly.  We say:
Implementations MUST support IPv4 and IPv6.  Dual stack support is NOT required and provider implementations MAY support separate interfaces for IPv4 and IPv6 by having more than one server in the appropriate SRV record where there is either an A or AAAA record in each server DNS record but not both.  The same version of IP MUST be used for both signaling and media of a call unless ICE [RFC8445] is used, in which case candidates may explicitly offer IPv4, IPv6 or both for any media stream. 

If there is any conflict between that and 8835, I don’t see it.

> WebRTC "browsers". It would help to clarify all this.
We’re not requiring anything normative from 8825 I think.  Only the parts we expressly state. I could add: “explicit requirements from the WebRTC suite of documents are described below”.