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

[Paul Kyzivat <[e-mail]>]

Hi James,

I'm happy to see you posting here.

On 2/12/20 7:28 AM, James Hamlin wrote:
> Brian
> 
> 
> We do need to be clear, that:-
> 
>   * A VRS user needs an account with a provider before they can use the
>     service.

With *a* provider. Given that, they can get service from another 
provider via dial around. And/or they can have accounts with multiple 
providers.

If the RUE supports connections to multiple providers, and also supports 
one-stage dial-around then the distinction between the two, at least for 
outgoing calls, will be subtle.

>   * Config settings, especially credentials and phone number, are only
>     valid for one user account, within the lifetime returned in the JSON
>     object
>   * A user-agent header should be supplied when retrieving configuration
>     so that configuration can be specific to the RUE

Agree.

The point I was trying to make is that each provider will want to 
maintain the config information for its own account. If the user has 
accounts with multiple providers, then the RUE needs to fetch the config 
information for each of them from the corresponding provider.

Separately the RUE will need common config information - notably which 
providers user has accounts with. I'm imagining that the RUE will hold 
that locally. If the user has multiple RUEs then it might be helpful to 
have some common place to store that common config information, but I 
don't know who would host it.

	Thanks,
	Paul

> Best regards
> 
> 
> James
> 
> 
> 
> 
> On 29/01/2020 23:04, 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.
>  >
>  > 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
>  >
>  >
> 
> 
>