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

I agree that the current language is not very clear, and not really what we want.  As Paul says, we’re defining an interface between a device and a provider.  We probably do care that if two rue-compliant devices talked to one another through a provider, that all the features worked, but I don’t think we would imply anything else about what a provider did.  I think we would probably say that we wished providers had rue-compatible endpoints at, for example, a CA position, but I don’t think an IETF spec could or should say anything like that.  

Brian

> On Sep 16, 2019, at 2:48 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> 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
>>> 
>>> 
>>> 
> 
> -- 
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum