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

[Brian Rosen <[e-mail]>]

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] <mailto:[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] <mailto:[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/ <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/ <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.