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

[Martin Duke <[e-mail]>]

Yep, cleared, thanks.

On Thu, Jan 20, 2022 at 6:51 AM Brian Rosen <[e-mail]> wrote:

> I submitted a -10 which I hope addresses your issues.
>
> Brian
>
>
> On Jan 4, 2022, at 7:06 PM, Martin Duke <[e-mail]> wrote:
>
> Hi Brian,
>
> Thanks for clearing things up! Replies inline.
>
> Besides the already-proposed changes, the main action item is my scope
> followup question to #3.
>
> On Thu, Dec 23, 2021 at 12:14 PM Brian Rosen <[e-mail]> wrote:
>
>> Thank you for your comments.  Please see inline
>>
>> On Dec 7, 2021, at 1:00 PM, Martin Duke via Datatracker <[e-mail]>
>> wrote:
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> See above, but I still may have to just remove that “non browser
>> endpoint” text, because it’s confusing people.
>>
>>
> OK, I look forward to seeing the new text.
>
>>
>> 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.
>>
>> 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.
>>
>
> The scope of this isn't clear to me. I would imagine the WebRTC end of the
> gateway *does* support the webRTC data channel standards, yes? So the
> gateway that you specify in this document is translating the WebRTC data
> channel into the Section 6.2 data channel.
>
> Aside from the scoping question,  I'm struggling to find economical
> alternative wording that makes it clearer. So I'm OK with keeping the 8835
> "data channel" exception.
>
>
>>
>> 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.
>>
>>
>> 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.
>>
>
> Sorry I missed that text somehow!
>
>>
>> 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.
>>
>> 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”.
>>
>
> I think that would improve clarity.
>
>>
>> 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.
>>
>>
>