Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 13 September 2019 19:12 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 A089E120105 for <rum@ietfa.amsl.com>; Fri, 13 Sep 2019 12:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 5NlRAl139nxo for <rum@ietfa.amsl.com>; Fri, 13 Sep 2019 12:12:46 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711221200FA for <rum@ietf.org>; Fri, 13 Sep 2019 12:12:46 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x8DJCgnP010371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Sep 2019 15:12:43 -0400
To: James Hamlin <james.hamlin@purple.us>, Richard Shields <richard@sorenson.com>, "rum@ietf.org" <rum@ietf.org>
References: <f3c1d9fe-8785-86e9-4220-e7d7971b29d4@alum.mit.edu> <ef8dec34-af0d-d4e4-be33-a28a0c9bd0b4@alum.mit.edu> <1568385648772.69603@purple.us> <MWHPR04MB09910881CB5EBC510E9A350CC5B30@MWHPR04MB0991.namprd04.prod.outlook.com> <1568387962077.82824@purple.us> <MWHPR04MB0991B268CB26104EF61AC058C5B30@MWHPR04MB0991.namprd04.prod.outlook.com> <1568390112344.87888@purple.us>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <da240598-fbed-8720-b045-b6b9edd11853@alum.mit.edu>
Date: Fri, 13 Sep 2019 15:12:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <1568390112344.87888@purple.us>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/r4w_LbY8llYRqK5QcH4HXBl8LBA>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 19:12:49 -0000

On 9/13/19 11:55 AM, James Hamlin wrote:
> Richard
> 
> Yes, but my understanding is that the RUE is a "WebRTC endpoint" and provider a "WebRTC-compatible endpoint" but the current text doesn't make any distinction.

I agree that we need to clarify that requirements differ between the RUE 
and the VRS provider. I think it is worth some discussion if the 
provider should be "WebRTC-compatible" or perhaps something more 
specific than that though not all the way to "WebRTC endpoint".

While the goal of the WG is just to specify the RUE, I think it may well 
be helpful to specify (somewhere) more about the environment in which it 
will be used, including the other pieces that play in that environment 
and interact with the RUE. For instance media relays, Interactive Media 
Response devices, Communications Assistant devices, video mail devices.

That will allow us to discuss constraints on the RUE that we need to 
consider and/or the potential need to develop requirements for some of 
those other devices.

	Thanks,
	Paul

> I just wanted to make sure that we will establish wording that makes clear points that are important for compatibility.
> 
> Best regards
> 
> James
> 
> 
> ________________________________________
> From: Richard Shields <richard@sorenson.com>
> Sent: 13 September 2019 16:22
> To: James Hamlin; rum@ietf.org
> Cc: Paul Kyzivat
> Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01
> 
> Thanks, James.
> 
> Section 5 of RFC 7742 states this:
> 
> "WebRTC-compatible endpoints" are free to implement any video codecs
>     they see fit.  This follows logically from the definition of "WebRTC-
>     compatible endpoint".  It is, of course, advisable to implement at
>     least one of the video codecs that is mandated for WebRTC browsers,
>     and implementors are encouraged to do so.
> 
> Does that not alleviate the requirement to implement VP8?
> 
> Thanks,
> Richard
> 
> -----Original Message-----
> From: James Hamlin [mailto:james.hamlin@purple.us]
> Sent: Friday, September 13, 2019 9:19 AM
> To: Richard Shields <richard@sorenson.com>; rum@ietf.org
> Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>
> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01
> 
> [EXTERNAL]
> 
> Richard
> 
> This was mentioned and I think the provider side is "WebRTC-compatible endpoint". But the text currently in 7.3 and 7.4 treats provider and RUE identically.
> 
> Best regards
> 
> James
> ________________________________________
> From: Richard Shields <richard@sorenson.com>
> Sent: 13 September 2019 16:02
> To: James Hamlin; rum@ietf.org
> Cc: Paul Kyzivat
> Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01
> 
> This may have been brought up before. RFC 7742, referenced in section 7.3, has three endpoint definitions: a WebRTC browser, a WebRTC non-browser, and a WebRTC-compatible endpoint,  with different levels of MTI regarding VP8. With the proposed RUE document, what are VRS endpoints considered?
> 
> Thanks,
> Richard
> 
> -----Original Message-----
> From: Rum [mailto:rum-bounces@ietf.org] On Behalf Of James Hamlin
> Sent: Friday, September 13, 2019 8:41 AM
> To: rum@ietf.org
> Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>
> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01
> 
> [EXTERNAL]
> 
> Paul
> 
> I think we agreed that OPUS and VP8 wouldn't need to be supported on the provider side, for good reasons. The draft proposed for adoption seems to contradict this with "RUE and Providers MUST" in sections 7.3 and 7.4 .
> 
> Is the procedure that the document is adopted, with some agreed changes missing, and then amended?
> 
> Best regards
> 
> James
> ________________________________________
> From: Rum <rum-bounces@ietf.org> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu>
> Sent: 10 September 2019 20:53
> To: rum@ietf.org
> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01
> 
> Reminder,
> 
> This call for adoption will end next Sunday. All responses so far have been in support, but there haven't been a lot of them. If you haven't yet responded, please do.
> 
>          Thanks,
>          Paul, as RUM co-chair
> 
> On 8/29/19 9:50 AM, Paul Kyzivat wrote:
>> This is a call for the adoption of draft-rosen-rue-01 as a RUM wg
>> document. This is intended to evolve into the document our charter
>> calls for.
>>
>> Comments, pro or con, on this proposal are due by Sunday September 15.
>>
>>       Thanks,
>>       Paul Kyzivat, as RUM co-chair
>>
> 
> --
> Rum mailing list
> Rum@ietf.org
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,XvDLRFtOorYTD_ZHqiyi_6x1eB_6gpdbTan7J17J5oZXHwBsGhr18IwuVwzvg_zkMdHAf0ubd1nNm-m4DNvAqH2M7I7ipp3wdXgwAUBL0XHEd7ncuIhgpdZkwg,,&typo=0
> 
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum
> 
> 
>