From nobody Mon Jan 24 12:52:20 2022 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6778B3A0C25; Mon, 24 Jan 2022 12:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMlHuFv_tMP5; Mon, 24 Jan 2022 12:52:10 -0800 (PST) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F5C3A0C02; Mon, 24 Jan 2022 12:52:09 -0800 (PST) Received: by mail-vk1-xa30.google.com with SMTP id w17so6899856vko.9; Mon, 24 Jan 2022 12:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L44R+A8naY85UD7QeQJ7CCAmVzk4aWY5nG5apX2F1sE=; b=NfYhTQOhuzTlFr4vmwwh1bBcmi+RX6YvZetd8GrLIL1iQ2T7zMjNMYvRTrd6wippfw MfeGFEbzVaJAbpSQuJLKEFFMwOdGzPu4+l8Lpk61ZG6tM2D3HwZw7fawpjo0qq/vY2wc UoFZw/2Ay6mh/1YQTEyR/6YoCuYkk5Pd2aDCx9aXOJ1HDUQxGomCJKrjTPIRXAdH5w4t 3rwl38DEovmE0nU3Edr9Cj3IIp+ERFFnL2x+D2CzT8emK8dvei+DqOmnZbbWxJqoXAUD gdMbo6GPxBMGvangsi9swFgImYTmZ3fKOwZFh1KMzecrg0qFfcC2g4/zMxTu5DA3uISm 7Orw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L44R+A8naY85UD7QeQJ7CCAmVzk4aWY5nG5apX2F1sE=; b=qrknyKEbGBQeHBHg5mR6F6su+/A5ygTc2Gk4kEFNY/IKfS7/wMin7gLpwvl03AmHKQ QeUWmM8suVK/mC9rNmFrfeBtxQfrv1FSLimjiIMtXJIKp04oKQiBoxTG+/3lD/uHljuj BvXkw/hr6zAZaOonI+Tjk28/x46cFVkT+T+Bt00g4NvqmUj6H+JITVEFLWpppA4walT0 tylowg46CMVrOMTR081D3rGM4T0OyTrPu94KJ5YTD4vSc/Qq+RC9LyjrclCKmh6iK3JC wZ7xqVQ/8Yx+rydnLmAA1iCk7R0YjhTq+X++81co2tRokjPGoR18SZ1it99YbGT85NdX JP0A== X-Gm-Message-State: AOAM5318kSSLG7jaL7zKimOnd2Rk1G4ERjTTmlW3Y6VLzTF+AbclCJZo XmFGVs8/II3GsSqyYtD2OUZme3nD44ltTeDcKyZ6kxsE X-Google-Smtp-Source: ABdhPJykpBIIBZTlzBdB+PuTV8YoqKofuk5ToGt7pVGZBoWiM/F+hc/vXdtgQ6Y3dDka6gAKf+Gunn4rSeHdv/A7Kso= X-Received: by 2002:a05:6122:130a:: with SMTP id e10mr3205248vkp.39.1643057527959; Mon, 24 Jan 2022 12:52:07 -0800 (PST) MIME-Version: 1.0 References: <163890001133.3603.6708235729467005454@ietfa.amsl.com> <47D5FC0F-129A-4227-8280-5DDC2D486BFB@brianrosen.net> <66F541E4-3415-49A8-A4C6-577F179A295E@brianrosen.net> In-Reply-To: <66F541E4-3415-49A8-A4C6-577F179A295E@brianrosen.net> From: Martin Duke Date: Mon, 24 Jan 2022 12:51:56 -0800 Message-ID: To: Brian Rosen Cc: The IESG , draft-ietf-rum-rue@ietf.org, rum-chairs@ietf.org, rum@ietf.org, Paul Kyzivat Content-Type: multipart/alternative; boundary="0000000000004cb5d305d65a242d" Archived-At: Subject: Re: [Rum] Martin Duke's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT) X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 20:52:15 -0000 --0000000000004cb5d305d65a242d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yep, cleared, thanks. On Thu, Jan 20, 2022 at 6:51 AM Brian Rosen wrote: > I submitted a -10 which I hope addresses your issues. > > Brian > > > On Jan 4, 2022, at 7:06 PM, Martin Duke 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 wrote: > >> Thank you for your comments. Please see inline >> >> On Dec 7, 2021, at 1:00 PM, Martin Duke via Datatracker >> 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 serve= r >> interface towards a browser, and a RUE client interface towards a provid= er >> is assumed. The gateway would interwork signaling, and as noted below, >> interwork at least any real time text media, in order to allow a standar= d >> 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 =E2=80=9Cnon browser >> endpoint=E2=80=9D text, because it=E2=80=99s confusing people. >> >> > OK, I look forward to seeing the new text. > >> >> 3. In Section 5.5, you require conformance with RFC8835 with a few vague= ly >> 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, rathe= r >> 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 =E2=80=9Cdata channel=E2=80= =9D in 8835 and it >> seems really obvious what does and doesn=E2=80=99t apply. Here is an ex= ample: >> >> For data transport over the WebRTC data channel [RFC8831 ], WebRTC >> endpoints MUST support SCTP over DTLS over ICE. This encapsulation >> is specified in [RFC8261 ]. Negotiation of this transport in the >> Session Description Protocol (SDP) is defined in [RFC8841 ]. The SCTP >> extension for I-DATA [RFC8260 ] MUST be supported. >> >> The setup protocol for WebRTC data channels described in [RFC8832 ] >> MUST be supported. >> >> >> None of it applies. It might not be quite as obvious that because the >> above doesn=E2=80=99t apply, there is no SCTP requirement, but do you th= ink we need >> to say that, given that the only discussion of SCTP is in relation to th= e >> 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 th= e > 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 883= 5 > "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 fo= r >> IPv4 and IPv6 by having more than one server in the appropriate SRV reco= rd >> 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=E2=80=99t see it. >> > > Sorry I missed that text somehow! > >> >> 5. In Sec. 6, it says "This specification adopts the media specification= s >> for >> WebRTC ([RFC8825])." Is this a normative statement? Must RUEs comply wit= h >> 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 no= t >> for >> WebRTC "browsers". It would help to clarify all this. >> >> We=E2=80=99re not requiring anything normative from 8825 I think. Only = the parts >> we expressly state. I could add: =E2=80=9Cexplicit requirements from the= WebRTC >> suite of documents are described below=E2=80=9D. >> > > 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 neede= d. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for your work to make the internet more accessible for all. >> >> > --0000000000004cb5d305d65a242d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yep, cleared, thanks.

=
On Thu, Jan 20, 2022 at 6:51 AM Brian= Rosen <br@brianrosen.net> w= rote:
I submitted a -10 which I hope addresses yo= ur issues.

Brian


On Jan 4, 2022, at 7:06 PM, Martin Duke <martin.h.duke@gmail.com>= ; wrote:

Hi Brian,

Thanks for clearing things up! Replies inline.

Besides the already-proposed changes, the main action ite= m is my scope followup question to #3.

=
On Thu, Dec 23, 2021 at 12:14 PM Bria= n Rosen <br@brian= rosen.net> wrote:
Thank you for your comments.=C2=A0 Please see inline

On Dec 7, 2021, at 1:00 PM, Martin Duk= e via Datatracker <noreply@ietf.org> 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
e= mail addresses included in the To and CC lines. (Feel free to cut this
i= ntroductory paragraph, however.)


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


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


------------------------------------------------------------= ----------
DISCUSS:
-------------------------------------------------= ---------------------

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

1. If I understand correctly, this d= raft is not at all about interoperating
with a WebRTC endpoint, instead = borrowing some requirements from that family of
specs rather than re-inv= enting the wheel. That's great, but putting that
explicitly in the i= ntro would be helpful.
Not quite.=C2=A0 I propo= se the following additional information in the media section where WebRTC s= pecs are discussed:
To use WebRTC with this document, a gateway t= hat presents a WebRTC server interface towards a browser, and a RUE client = interface towards a provider is assumed.=C2=A0=C2=A0The gateway would inter= work=C2=A0signaling, and as noted below, interwork at least any real time t= ext media, in order to allow a standard browser baed WebRTC client to be a = VRS client.=C2=A0=C2=A0The combination of the browser client=C2=A0and the g= ateway would be a RUE user.
2. In pa= rticular, the statement that RUE is a "non-browser endpoint" isconfusing 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 =E2=80=9Cnon browser endpoint=E2=80=9D text, because it=E2=80=99s con= fusing people.


O= K, I look forward to seeing the new text.=C2=A0=C2=A0
=

3. In Section 5.5, you require conformance with RFC8835 with a few= vaguely
worded exceptions. It would be helpful to actually go through t= hat document
enumerate exactly which normative statements in 8835 do not= apply. That said,
I'm not sure I agree with Bernard that 8835 requi= res *use* of ICE, rather than
support, but maybe we can clarify this in = the TSVART thread.
The only reference to 8835 r= eads:
Implementations MUST conform to [RFC8835]=C2=A0except for i= ts guidance on the WebRTC data channel, which this specification does not u= se.=C2=A0

I have looked carefully at all mentions = of =E2=80=9Cdata channel=E2=80=9D in 8835 and it seems really obvious what = does and doesn=E2=80=99t apply.=C2=A0 Here is an example:

   For data transport over the WebRTC data c=
hannel [RFC8831], WebRTC
   endpoints MUST support SCTP over DTLS over ICE.  This encapsulation
   is specified in [RFC8261].  Negotiation of this t=
ransport in the
   Session Description Protocol (SDP) is defined in [RFC8841].  The SCTP
   extension for I-DATA [RFC8260] MUST be supported.

   The setup protocol for WebRTC data channels described in [RFC8832]
   MUST be supported.

None of it applies.=C2=A0 It might not be q= uite as obvious that because the above doesn=E2=80=99t apply, there is no S= CTP 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 ca= ll out each one of the data channel statements, but it really does seem sup= erfluous.

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 s= pecify in this document is translating the WebRTC data channel into the Sec= tion 6.2 data channel.

Aside from the scoping ques= tion,=C2=A0 I'm struggling to find economical alternative wording that = makes it clearer. So I'm OK with keeping the 8835 "data channel&qu= ot; exception.
=C2=A0

4. As Bernard= points out, this ambiguity extends to IPv4 and 6 support. The
8835 requ= irements are specific to browsers, so they might not apply. If you
requi= re support for both, but not necessarily on the same device, it would begood to say so.

We require supp= ort for IPv4 and IPv6 expressly.=C2=A0 We say:
Implementations MU= ST support IPv4 and IPv6.=C2=A0=C2=A0Dual stack support is NOT required and= provider implementations MAY support separate interfaces for IPv4 and IPv6= by having more than one server in=C2=A0the appropriate SRV record where th= ere is either an A or AAAA record in each server DNS record but not both.= =C2=A0=C2=A0The same version of IP MUST be used for both signaling and medi= a of a call unless=C2=A0ICE [RFC8445]=C2=A0is used, in which case candidate= s may explicitly offer IPv4, IPv6 or both for any media stream.=C2=A0
=

If there is any conflict between that and 8835, I don= =E2=80=99t see it.

Sorry I miss= ed that text somehow!=C2=A0

5. In Sec. 6, it = says "This specification adopts the media specifications for
WebRTC= ([RFC8825])." Is this a normative statement? Must RUEs comply with th= e
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 "en= dpoints", but not for
WebRTC "browsers". It would help to= clarify all this.
We=E2=80=99re not requiring = anything normative from 8825 I think.=C2=A0 Only the parts we expressly sta= te. I could add: =E2=80=9Cexplicit requirements from the WebRTC suite of do= cuments are described below=E2=80=9D.

=
I think that would improve clarity.=C2=A0
<= div>
It's also possible that my initial understanding is incorrect, = in which case
the later points don't make any sense and some explana= tory text is needed.


-------------------------------------------= ---------------------------
COMMENT:
--------------------------------= --------------------------------------

Thanks for your work to make = the internet more accessible for all.
<= /blockquote>

--0000000000004cb5d305d65a242d--