Re: [Rum] draft-ietf-rum-rue-02.txt: Configuration

[Paul Kyzivat <[e-mail]>]

On 1/29/20 6:04 PM, Brian Rosen wrote:
> The configuration file mechanism needs work.
> The current mechanism supports multiple providers in that it allows multiple username/passwords.
> That’s probably insufficient.  For example, each provider may have their own TURN server.  Probably, we want to allow any of the parameters to be either in the “top level” part of the object, in which case they apply globally, or in a per-provider part of the object in which case it only applies to that provider.

IMO that isn't good enough. It just isn't workable for a single config 
file to contain one RUE's config information for multiple providers. 
Where would it live, and who would manage it? Each provider needs to be 
able to manage its own config data.

Perhaps there should be *some* config data that is per-RUE rather than 
per-provider account, and is managed by the end user rather than the 
providers. For instance, the user might want to make his own choice of 
where to sync his address book instead of or in addition to a 
provider-managed server. But I think that could be a local config issue 
between the RUE and the user.

	Thanks,
	Paul

> There is also the issue of cleartext passwords.
> 
> I was thinking about that, but didn’t really work out a solution.  What I’m thinking about is that maybe there is a single username/password that unlocks the file, and in the file are per-provider records.  The device itself manages the encrypt and decrypt of the file.
> 
> I wondered if we could use .well-known, plus that username, to find the file at the default provider’s website, as listed in the provider file, but the user may have more than one TN at more than one default provider, so I got back to a pre-provisioned URI.
> 
> This update does address all the issues I knew about.
> 
> I got a private email that told me the example config file didn’t lint, and I found two errors that I’ll get into the next revision.  Since we’re likely to change that part of the document anyway, that’s no big deal.
> 
> Someone also asked about why we specified STUN/TURN in the config, but didn’t mention it anywhere else.  It gets into the requirements via the WebRTC transport spec, which requires ICE, which requires STUN/TURN.  So technically, it’s okay, but do we want to point that out?
> 
> Brian
> 
> 
>> On Jan 29, 2020, at 5:51 PM, Paul Kyzivat <[e-mail]> wrote:
>>
>> Brian,
>>
>> Thanks for the update. I think I will have a number of questions once have more time for study, but I have one right off:
>>
>> Section 9 says that there is one file for device configuration. That won't make it practical for a single RUE to support a user with accounts with multiple providers. Rather, to be workable it will be necessary for there to be a configuration file for each provider that the user of the RUE uses.
>>
>> The exact mechanism for setting that up needs to be worked out. Perhaps it would be sufficient for there to be another entry, for each provider, in the provider list file that is used by the RUE to retrieve the configuration for that provider.
>>
>> 	Thanks,
>> 	Paul
>>
>> On 1/29/20 4:47 PM, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Relay User Machine WG of the IETF.
>>>          Title           : Interoperability Profile for Relay User Equipment
>>>          Author          : Brian Rosen
>>> 	Filename        : draft-ietf-rum-rue-02.txt
>>> 	Pages           : 28
>>> 	Date            : 2020-01-29
>>> Abstract:
>>>     Video Relay Service (VRS) is a term used to describe a method by
>>>     which a hearing persons can communicate with deaf/Hard of Hearing
>>>     user using an interpreter ("Communications Assistant") connected via
>>>     a videophone to the deaf/HoH user and an audio telephone call to the
>>>     hearing user.  The CA interprets using sign language on the
>>>     videophone link and voice on the telephone link.  Often the
>>>     interpreters may be supplied by a company or agency termed a
>>>     "provider" in this document.  The provider also provides a video
>>>     service that allows users to connect video devices to their service,
>>>     and subsequently to CAs and other dead/HoH users.  It is desirable
>>>     that the videophones used by the deaf/HoH/H-I user conform to a
>>>     standard so that any device may be used with any provider and that
>>>     video calls direct between deaf/HoH users work.  This document
>>>     describes the interface between a videophone and a provider.
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-rum-rue-02
>>> https://datatracker.ietf.org/doc/html/draft-ietf-rum-rue-02
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-02
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>
>> -- 
>> Rum mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rum
>