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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Sep 2019 15:53:34 -0400

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
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 10 Sep 2019 15:05:23 -0500

I support adoption.

> On Sep 10, 2019, at 2:53 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> 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
> 
>> 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.
> --
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: James Hamlin <[email-masked]>
Date: Fri, 13 Sep 2019 14:40:48 +0000

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 <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: 10 September 2019 20:53
To: [email-masked]
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

Reminder,

        Thanks,
        Paul, as RUM co-chair

--
Rum mailing list
[email-masked]
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

---

From: Richard Shields <[email-masked]>
Date: Fri, 13 Sep 2019 15:02:55 +0000

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:[email-masked]] On Behalf Of James Hamlin
Sent: Friday, September 13, 2019 8:41 AM
To: [email-masked]
Cc: Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[EXTERNAL] 

Paul

 
Best regards

James

Reminder,

        Thanks,
        Paul, as RUM co-chair

On 8/29/19 9:50 AM, Paul Kyzivat wrote:
> document. This is intended to evolve into the document our charter 
> calls for.
>

---

From: James Hamlin <[email-masked]>
Date: Fri, 13 Sep 2019 15:19:21 +0000

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 <[email-masked]>
Sent: 13 September 2019 16:02
To: James Hamlin; [email-masked]
Cc: Paul Kyzivat
Subject: RE: [Rum] Call for WG adoption of: draft-rosen-rue-01

Thanks,
Richard

-----Original Message-----
From: Rum [mailto:[email-masked]] On Behalf Of James Hamlin
Sent: Friday, September 13, 2019 8:41 AM
To: [email-masked]
Cc: Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[EXTERNAL]

Paul

Best regards

James

Reminder,

        Thanks,
        Paul, as RUM co-chair

---

From: Richard Shields <[email-masked]>
Date: Fri, 13 Sep 2019 15:22:29 +0000

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:[email-masked]] 
Sent: Friday, September 13, 2019 9:19 AM
To: Richard Shields <[email-masked]>; [email-masked]
Cc: Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[EXTERNAL] 

Richard

Best regards

James

Thanks,
Richard

-----Original Message-----
From: Rum [mailto:[email-masked]] On Behalf Of James Hamlin
Sent: Friday, September 13, 2019 8:41 AM
To: [email-masked]
Cc: Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[EXTERNAL]

Paul

Best regards

James

Reminder,

        Thanks,
        Paul, as RUM co-chair

---

From: James Hamlin <[email-masked]>
Date: Fri, 13 Sep 2019 15:55:12 +0000

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 just wanted to make sure that we will establish wording that makes clear points that are important for compatibility. 

Best regards

James

Sent: 13 September 2019 16:22

Thanks, James.

Thanks,
Richard

-----Original Message-----
From: James Hamlin [mailto:[email-masked]]
Sent: Friday, September 13, 2019 9:19 AM
To: Richard Shields <[email-masked]>; [email-masked]
Cc: Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[EXTERNAL]

Richard

Best regards

James

Thanks,
Richard

-----Original Message-----
From: Rum [mailto:[email-masked]] On Behalf Of James Hamlin
Sent: Friday, September 13, 2019 8:41 AM
To: [email-masked]
Cc: Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[EXTERNAL]

Paul

Best regards

James

Reminder,

        Thanks,
        Paul, as RUM co-chair

---

From: Richard Shields <[email-masked]>
Date: Fri, 13 Sep 2019 16:04:29 +0000

Hi James,

I agree that the wording could use clarification. The phrase, "MUST conform" in 7.3 and the phrase, "not constrained by this specification" in RFC 7742 seemed confusing to me and is why I asked my question regarding what type of endpoint VRS endpoints are considered.

Thanks,
Richard

-----Original Message-----
From: James Hamlin [mailto:[email-masked]] 
Sent: Friday, September 13, 2019 9:55 AM
To: Richard Shields <[email-masked]>; [email-masked]
Cc: Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[EXTERNAL] 

Richard

Best regards

James

Thanks, James.

Thanks,
Richard

-----Original Message-----
From: James Hamlin [mailto:[email-masked]]
Sent: Friday, September 13, 2019 9:19 AM
To: Richard Shields <[email-masked]>; [email-masked]
Cc: Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[EXTERNAL]

Richard

Best regards

James

Thanks,
Richard

-----Original Message-----
From: Rum [mailto:[email-masked]] On Behalf Of James Hamlin
Sent: Friday, September 13, 2019 8:41 AM
To: [email-masked]
Cc: Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

[EXTERNAL]

Paul

Best regards

James

Reminder,

        Thanks,
        Paul, as RUM co-chair

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Sep 2019 15:12:42 -0400

> 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

---

From: Isaac Roach <[email-masked]>
Date: Sat, 14 Sep 2019 19:01:41 -0600

Hi Paul,

Sorenson has concerns about using the current draft as the starting point
for the working group. For example, Sorenson agrees with your earlier
comments highlighting the security issues that the draft presents and that
it doesn't solve the client cert issue. I also am concerned about how the
draft addresses 911, requiring endpoints to comply with RFC6881 and to send
geolocation information, rather than using the method that the FCC’s rules
require (Registered Location).  Sorenson would be concerned if these issues
become part of a WG document.

Thanks,

Isaac

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Sep 2019 11:18:24 -0400

Isaac,

On 9/14/19 8:59 PM, Isaac Roach wrote:
> Hi Paul,
> Sorenson has concerns about using the current draft as the starting 
> point for the working group.

Right now this is the only candidate we have. Unless there is an 
indication that an alternative is forthcoming it will be a matter of an 
bird in the hand vs another in the bush.

If you wish to make an alternative proposal I am willing to help you 
with the mechanics of doing so.

Adopting this does not prevent addressing the points you raise below.

> For example, Sorenson agrees with your 
> earlier comments highlighting the security issues that the draft 
> presents and that it doesn't solve the client cert issue.

It would be helpful to have a discussion of the issue you want to solve. 
I sketch out my understanding of it in my comments. But if I properly 
understand your concerns then I don't know any way to satisfy them. And 
ISTM that web server developers should have similar concern about 
browsers and yet they manage without any similar verification.

> I also am 
> concerned about how the draft addresses 911, requiring endpoints to 
> comply with RFC6881 and to send geolocation information, rather than 
> using the method that the FCC’s rules require (Registered Location).  

I hope Brian Rosen will respond to this, since he is expert in 911 issues.

> Sorenson would be concerned if these issues become part of a WG document.

Again, adopting this draft does not preclude subsequently addressing 
these issues. Your issues will need to be resolved one way or another 
before the resulting document can survive a last-call.

	Thanks,
	Paul

> Thanks,
> 
> Isaac
> 
> On Thu, Aug 29, 2019 at 7:51 AM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     calls
>     [email-masked] <mailto:[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Sep 2019 11:24:22 -0400

With respect to 9-1-1: 
Devices don’t have any requirements to be able to support classic emergency calling (what we would call E9-1-1 in the US) other than, perhaps, the ability to dial a “service code”, like 9-1-1 or 3-1-1.  

With NG9-1-1 and the equivalents in the EU and elsewhere, the device has to conform to RFC6881.

Brian

> On Sep 16, 2019, at 11:18 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Isaac,
> 
>> Sorenson has concerns about using the current draft as the starting point for the working group.
> 
> Right now this is the only candidate we have. Unless there is an indication that an alternative is forthcoming it will be a matter of an bird in the hand vs another in the bush.
> 
> If you wish to make an alternative proposal I am willing to help you with the mechanics of doing so.
> 
>> For example, Sorenson agrees with your earlier comments highlighting the security issues that the draft presents and that it doesn't solve the client cert issue.
> 
> It would be helpful to have a discussion of the issue you want to solve. I sketch out my understanding of it in my comments. But if I properly understand your concerns then I don't know any way to satisfy them. And ISTM that web server developers should have similar concern about browsers and yet they manage without any similar verification.
> 
>> I also am concerned about how the draft addresses 911, requiring endpoints to comply with RFC6881 and to send geolocation information, rather than using the method that the FCC’s rules require (Registered Location).  
> 
> Again, adopting this draft does not preclude subsequently addressing these issues. Your issues will need to be resolved one way or another before the resulting document can survive a last-call.
> 
> 	Thanks,
> 	Paul
> 
>> Thanks,
>> Isaac
>> On Thu, Aug 29, 2019 at 7:51 AM Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>>    --     Rum mailing list

---

From: James Hamlin <[email-masked]>
Date: Mon, 16 Sep 2019 16:15:21 +0000

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". 

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.

Best regards

James 

________________________________________
From: Paul Kyzivat <[email-masked]>
Sent: 13 September 2019 20:12
To: James Hamlin; Richard Shields; [email-masked]
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

        Thanks,
        Paul

> 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
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Sep 2019 14:48:56 -0400

James,

> "... 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…

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 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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Sep 2019 15:07:06 -0400

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 <[email-masked]> wrote:
> 
> James,
> 
> 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.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Sep 2019 15:27:58 -0400

> 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-co…

Perhaps it would be helpful to have the draft reference Drawing 1 of:

VRS US Providers Profile TWG-6-1.0 
<https://www.sipforum.org/download/vrs-us-providers-profile-twg-6-1-0-pdf/?wpdmdl=2783&refresh=5d7fdfea794471568661482>

and say that the goal is to define interface U2. That diagram was 
developed in the early days of the SIP Forum work on VRS. At that time 
the scope was expected to be broader, but was eventually limited to the 
R1 interface. This figure gives an overview of the bigger picture and 
helps put the work into context.

(Note that a revision to that profile is in progress, but it won't 
change that figure.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Sep 2019 16:32:14 -0400

RUM followers:

The deadline for comments on the call for adoption of draft-rosen-rue-01 
concluded on Sunday Sept 15.

Summarizing the comments that came in:

- 8 people indicated a desire to adopt;
- 3 people expressed some concerns with the document.

In my judgement the concerns raised are all worth of further pursuit. 
But I don't see any problem in addressing those via revisions to the 
proposed document. Since no alternative document has been offered, I 
conclude that we should adopt draft-rosen-rue-01 as a working group 
document aimed at satisfying our sole milestone: "Submit a profile of 
SIP and media features for use with video relay services to the IESG for 
publication".

The author is requested to submit a new version of the document ASAP, 
with the name changed to: draft-ietf-run-rue-00 signifying it as a WG 
document.

I also request that people now start posting to this mailing list issues 
with this document. Where possible, please start a separate thread with 
a meaningful title for each issue in order to facilitate orderly 
discussion of the issues. Note that once we seem to have consensus on 
the resolution to an issue then suggestions of specific text changes are 
welcome.

	Thanks,
	Paul (as RUM co-chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Sep 2019 17:36:25 -0400

Roger,

On 9/18/19 3:32 PM, Roger Slusser wrote:
> Paul,
> Think there is a typo maybe...
> 
>     draft-ietf-run-rue-00
> 
> Should it be draft-ietf-rum-rue-00:

Right. I was just checking to see if you were paying attention. :-)

	Paul

> Roger Slusser
> To: rum <[email-masked]>
> Sent: Tue, Sep 17, 2019 4:32 pm
> Subject: [Rum] Adoption of draft-rosen-rue-01 as a RUM WG draft
> 
> RUM followers:
>

---

From: Roger Slusser <[email-masked]>
Date: Wed, 18 Sep 2019 19:32:34 +0000 (UTC)

Paul,Think there is a typo maybe... 

draft-ietf-run-rue-00

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
To: rum <[email-masked]>
Sent: Tue, Sep 17, 2019 4:32 pm
Subject: [Rum] Adoption of draft-rosen-rue-01 as a RUM WG draft

RUM followers:

    Thanks,
    Paul (as RUM co-chair)