Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt

[James Hamlin <[e-mail]>]

Hi Paul

Agreed, the background to this is that VRS Providers wish to provide controlled, limited access to 3rd party applications so as to protect their services from bad actors and misbehaving Apps. And I don't think a solution had been fully agreed.

Best regards

James


James Hamlin
Contractor
Purple, a Division of ZP Better Together, LLC
purplevrs.com
The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.

________________________________________
From: Paul Kyzivat <[e-mail]>
Sent: 21 September 2020 15:47
To: James Hamlin
Cc: [e-mail]
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt

James,

Since you are the one VRS Provider person who regularly contributes
here, can I ask you to help a bit more?

Back when we started this work with Henning several years ago a major
concern of the providers was to find a mechanism to easily and cheaply
restrict access to RUE implementations that have been tested/certified.
The goal as I understand it was to avoid subjecting the provider systems
to attacks. But to date we haven't identified a mechanism for doing this
that actually works. At the moment there is nothing in the draft for that.

I have been arguing that web servers don't limit access to certified web
browsers and they manage to survive. But still I am willing to entertain
including a mechanism if we could find one that is workable.

Would you be willing to work on this with us? In particular, to start,
identify the particular concerns and the level of effort that is/isn't
acceptable to identify and reject uncertified clients.

        Thanks,
        Paul

On 9/21/20 5:04 AM, James Hamlin wrote:
> Brian
>
>
> Thanks for the new draft.
>
>
> I think the final sentence in section 5.2.5. "Emergency Calls" is out of
> scope, as it tries to define the interface between the VRS provider and
> the PSAP. From the rest of the text, the purpose of the data exchange
> between RUE and VRS provider is already clear; the final sentence could
> be dropped without detracting from the description of the RUM interface.
> I propose dropping the text/: "Providers MUST implement Data Provider
> and Service Information blocks as the call is forwarded to the PSAP."./
>
>
> Best Regards
>
>
> James
>
>
> James Hamlin
> Contractor
> Purple, a Division of ZP Better Together, LLC
> purplevrs.com
>
> The information contained in this e-mail message is intended only for
> the personal and confidential use of the recipient(s) named above. If
> you have received this communication in error, please notify us
> immediately by e-mail, and delete the original message.
>
>