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

Brian Rosen <br@brianrosen.net> Wed, 29 January 2020 23:04 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D616E12004C for <rum@ietfa.amsl.com>; Wed, 29 Jan 2020 15:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX6RV5KA9Hii for <rum@ietfa.amsl.com>; Wed, 29 Jan 2020 15:04:21 -0800 (PST)
Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A3E120047 for <rum@ietf.org>; Wed, 29 Jan 2020 15:04:21 -0800 (PST)
Received: by mail-yw1-xc2a.google.com with SMTP id h126so893057ywc.6 for <rum@ietf.org>; Wed, 29 Jan 2020 15:04:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LessnoYMQnLkQ1ON+D/jn8LUI4wPwEyiLNh/wstQ5FA=; b=p5VUKnYfuoKlggeaQM5mRyXPnAWkQfQBx7yynBtzIBe0a7171eHoDs9EjXDy3afFtg MOIz/555YwM6Td5j+1DZT7UC0dRuWjOENM00z2bF8uZIBH5QsY2IcElW4jZa2nIAMVJS P2Y/DbnJUE+YlBYUIbIeZ9Ftr3+b3zXnSw+ErzTNH1KLAQw41x78dQDbTcq3NYE0rky/ dEatNJQbjugy+aJzQ/eKyoRT7rbAdX5Gqhj3Z5HnFmDAs78LcIdAOXYIa79zuVoaH1gS DBIOCGlUxBODRW96bqYVJXZXW5Ql7s46uxZduTKSVKxjoPfLf5uz1PdfhuG/+ZllSakz E6DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LessnoYMQnLkQ1ON+D/jn8LUI4wPwEyiLNh/wstQ5FA=; b=T7RoqE4uivLjU756Rr6waMGOsVfxV+XpZu3hpUdEOzjC5j/mps9hYNG8QKknHwY8DJ +MMJtd+nE8QLNWjlr3/RQIhDvGdjyAxZfOrT1Ql2+hFSuqk8i06Tbdj2vZaxjB26vJmg wW9pF1It36MOvFiBKmyVC5ulr+f2+WDiftkeoFUnLGhdne2aKhiQ4OXHQfKzDTA+GMxj TvqCHWlg0QX0IIvABQQvG/GN9YEBOfqZRR8zKnghHcfmAIE69HDlxLc/Oxkb3gn3Cnq3 Uue3yBHmQ72UN26VQqjQ1GG+1lZOE1EAos7tQYSns2Ab44TIhrbcvmQv/F7ma6/6WPVw L0qA==
X-Gm-Message-State: APjAAAWLsz9Fk3cYtJJsJ6mlDDuJfJ96GM/1Y9jNSgLlsRP4JCmtwDBP WxkzA+BgDv2GnZWdJ97acezSlg==
X-Google-Smtp-Source: APXvYqz+GT+18hRnEEk774hAO0JMnrTAqFIjFd9tIcQ6zOWbncXrnCkgf0TFdT2aELt1ZZBKowoctg==
X-Received: by 2002:a25:cf0b:: with SMTP id f11mr1609142ybg.469.1580339060335; Wed, 29 Jan 2020 15:04:20 -0800 (PST)
Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id o205sm1617265ywb.58.2020.01.29.15.04.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jan 2020 15:04:20 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <d1156d7d-59fb-6af3-7968-822f579b9a46@alum.mit.edu>
Date: Wed, 29 Jan 2020 18:04:18 -0500
Cc: rum@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A8D04E67-DC30-42D6-A2DA-CFEBD8E45DF9@brianrosen.net>
References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> <d1156d7d-59fb-6af3-7968-822f579b9a46@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/bUJz-eOFuZxy7OVOv-XNjuRfB1w>
Subject: Re: [Rum] draft-ietf-rum-rue-02.txt: Configuration
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2020 23:04:24 -0000

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 <pkyzivat@alum.mit.edu> 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, internet-drafts@ietf.org 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
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum