Subject: [Rum] I-D Action: draft-ietf-rum-rue-02.txt

From: [email-masked]
Date: Wed, 29 Jan 2020 13:47:13 -0800

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/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Jan 2020 17:51:13 -0500

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 29 Jan 2020 18:04:18 -0500

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 <[email-masked]> 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
> 
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Jan 2020 22:03:01 -0500

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Jan 2020 13:00:18 -0500

Here are some further comments on -02:

This update has largely expunged separate specifications for the RUE and 
the provider server the RUE connects to in favor of talking about the 
RUE Interface that both are required to implement. In some cases that 
makes sense because the requirements are the same on both sides. In 
other cases it seems to dodge the issue that the two sides have 
different roles and responsibilities. For instance: RFC5626 (outbound), 
RFC6665 (events), RFC6442 (geoloc).

Section 5.2.1 now says:

    The all outbound calls MUST be routed through an outbound proxy if
    configured.

(It previously specified the RUE.) IIUC this really does only apply to 
the RUE. AFAIK we don't specify any configuration for the provider, and 
presumably providers can do whatever they want that works. (Also, the 
language is a bit messed up.)

Section 5.2.3 says:

    To identify the owner of a RUE, the initial INVITE for a call from a
    RUE, or the 200 OK accepting a call by a RUE, identifies the owner by
    sending a Call-Info header with a purpose parameter of "rue-owner".

This new purpose parameter needs to be registered with IANA. It 
currently isn't mentioned in section 11.

Section 5.2.5 says:

    The implementations comply with [RFC6881] for handling of emergency
    calls.

This is not a normative statement. AFAICT there is no normative 
requirement to support this. And this is another asymmetric case. (IIUC 
the provider need not include GeoLoc in outbound calls to the RUE.)

This section also uses "client" and "server" to refer to the RUE and 
Provider sides of a RUE Interface. This differs from using "client" to 
refer to UAC and "server" for UAS.

Section 5.5 and elsewhere use the following construction:

    Implementations MUST conform to ... with the understanding that ...

That language seems a bit vague to me. Is this relaxing any normative 
statements in the reference, or simply stating that only a subset of the 
standard will be used in practice? I'd like to see this tightened up 
normatively.

Section 6.3:

I think this is saying that RUEs MUST support VP8 unless they can't, 
while providers MUST *support* VP8 but need not use it in every call, 
such as when connecting to another endpoint that doesn't. I get the 
spirit, but it fails to make clear when an implementation is non-conforming.

For instance, is it acceptable for a provider's interpreters to use 
non-RUE devices that don't support VP8? Is it acceptable for the 
provider video-mail server to not support VP8?

Section 8:

IIUC this means that the provider may or may not include a "mwi" entry 
in the configuration, but if it is configured that both sides are 
required to support it as specified.

Section 9.1:

This makes it optional for a RUE to make the choice of provider 
available to the user. Is that what we want?

Section 9.3:

These schemas use the [JCR] notation. This dates back to the early 
versions of this document several years ago. At the time there was 
single accepted schema notation for JSON. JCR was under development at 
the time. I haven't kept up with what has been happening with JSON 
schemas. I just looked and it appears that 
draft-newton-json-content-rules-09 is the latest version of JCR. I don't 
know if that means it was abandoned in favor of something else. We need 
to investigate this.

	Thanks,
	Paul