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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 16 September 2019 18:49 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 6580D120122 for <rum@ietfa.amsl.com>; Mon, 16 Sep 2019 11:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 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] 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 SxeQh5MZ_CK4 for <rum@ietfa.amsl.com>; Mon, 16 Sep 2019 11:49:01 -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 62893120890 for <rum@ietf.org>; Mon, 16 Sep 2019 11:49:01 -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 x8GImu7t014996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Sep 2019 14:48:57 -0400
To: James Hamlin <james.hamlin@purple.us>, "rum@ietf.org" <rum@ietf.org>
Cc: Richard Shields <richard@sorenson.com>
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> <da240598-fbed-8720-b045-b6b9edd11853@alum.mit.edu> <1568650521915.9877@purple.us>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <075887d0-fa00-ed1a-e2de-0ea35e077d41@alum.mit.edu>
Date: Mon, 16 Sep 2019 14:48:56 -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: <1568650521915.9877@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/oRNhkGJGKHLkEDdzNXu9fX8Ip70>
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: Mon, 16 Sep 2019 18:49:09 -0000

James,

On 9/16/19 12:15 PM, James Hamlin wrote:
> Paul
> 
> "... the goal of the WG is just to specify the RUE..." isn't consistent with the charter which, talks of a "a RUM-compliant provider" and the document scope which contains things like "the provider MUST".

OK. I shouldn't think about it that way. After rereading the charter I 
find it isn't very clear and concise about exactly what is and isn't in 
scope. It is really the interface between a RUE and a provider, and that 
has two sides.

> I don't think we will need to peer inside provider's networks except to point out - as we have - that there are some limitations on what codecs can realistically be offered at the provider's side of the RUE interface.
> 
> I think the text will need to recognise - as previous versions have done - some asymmetry between the RUE which is new and providers which are established.

I agree that we need to acknowledge this asymmetry.

	Thanks,
	Paul

> Best regards
> 
> James
> 
> 
> ________________________________________
> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> Sent: 13 September 2019 20:12
> To: James Hamlin; Richard Shields; rum@ietf.org
> Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01
> 
> 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://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2frum&c=E,1,5gFM03FhLeAehgyM5wopwvqisH_DKkNfsMVfqIMUtoJYZexefZEADQ9aHKc-74KC8XOuzmOWQEvBaAcc6pYgXOkk4ObSl_YHXWvalJG72uy_OQ6v038vyjCsoVU3&typo=0
>>
>>
>>
> 
>